ANSI/ISO is fine for basic C.R.U.D. but since the manufacturers of various RDBMSs don't actually follow ANSI/ISO 100%, then trying to achieve pure ANSI/ISO does nothing more than to restrict you from using the more powerful extensions they provide. Certainly, it doesn't make your code portable.
I agree that the column name of "ID" is inappropriately non-descript but the concept of an "ID" column will continue until there's an RDBMS that actually allows for the simple construction and use of a solid natural key. A perfect example is that of a Customer table. Trying to come up with a meaningful bullet proof, easy to generate, use, and maintain natural key on such a table is virtually useless because it doesn't actually prevent the same customer from being entered into the table more than once.
The concept of a "master" table does exist in RDBMSs, although I do agree the name "Master" is as non-descript as "ID". The classic Invoice/Invoice Detail table combination is proof of the "master/slave" concept. The "slave" (InvoiceDetail row) must not exist before the "master" (Invoice row) does.
"Pointer Chains" are essential in SQL especially when it comes to hierarchies (you should actually know that based on the very book you've recommended). Even Nested Sets rely on them. They're also key to the summarization of data using certain aggregates based on things like PRECEEDING ROWS, etc. Without them, you would have to rely on the "natural order" in a table and we know how bad an idea that is since there are no such guarantees as to order.
Of course, if you only use SQL Server as a place to store data, none of that matters but don't expect any performance from your system if you do, especially in the "other" world of high performance batch processing.