Publishing the article as is (with advice that will lead beginners astray) is OK. Promoting it as the headline article in the daily email is somewhat of an editorial blunder in my book.
I have found that SQL Server does a pretty good job of selecting a good execution plan if I:
1: Write queries with sets in mind,
2: Have the proper indexes on the tables,
3: Avoid constructions that doesn't allow use of those indexes (be careful with the use of functions and expressions in WHERE clauses, but it is not always bad),
4: Avoid stored procedures with parameter based logic that confuses the optimizer: I had an example where another developer had written an SP that performed three similar but different functions (with different execution plans). Every (!) time the SP was executed, the optimizer chose the wrong plan. I split it into three separate SPs, and had the application determine which one to execute, which took the procedure from occasionally timing out after (extended timeout) of 45 seconds, to sub-second response.
5: Handling large datasets (10 million rows and up) may require rethinking some things. While selecting a few rows from a multi-million row table using an index with good selectivity is vastly different from performing mass operations.
(Since Oracle has been mentioned... :->) The two biggest differences between Oracle and SQL Server:
a) With Oracle, you have more tools and features to tweak performance
b) With Oracle, you have to know and use those tools to get consistent performance