>> Also, considering that VALUES didn't actually come out until 2008, your lecture about getting rid of the old syntax "decades" ago is full of hooie.<<
Looking over my old ANSI standards, I see the values clause was always there. Originally, it was used for inserting a single row at a time; we did not get the table constructor syntax until later (I can't remember which release of the standard that was).
The SQL–92 standard added the "default values" option, which had never actually seen used in production.
If my arithmetic is correct, 2008 is 11 years ago, so we have two decades here and we are in the process of the second decade. Picky, picky.
>> As for someone's data being similar to what was on punched cards, so what? <<
A problem with thinking of row by row data processing (which is one of your manias) is that you are simulating a punch card reader by putting insert statements for each row, in the input sequence that has to be committed. When you use a table construction in the values clause, the optimizer is free to sort the rows or do anything else that wants to with them before it puts the set into the target table. Here's a chance for optimization. It does not exist with punchcard data.. I honestly don't know how much optimization SQL Server does with the insert into statement the current releases.
Please post DDL and follow ANSI/ISO standards when asking for help.