You *completely* missed the real argument:
Drupal is modular. Modules tend to have their own tables. Often these are 1::1 tables.
You misinterpreted my post. I said the 1::1 tables created by content types are fine. We're talking about core tables here, like {node_comment_statistics} that have columns often used in WHERE or ORDER BY criteria.
I think Earl does not want you to make any such discrimination. IMO, you're compromising design integrity for performance. The comment module is, whilst still a core module, an *optional* component. Some installations/distributions might use it. Some installations might not. Some installations might have a drop in replacement for it. For e.g., the project module, IIRC, does not use the comment module and still uses its own table. I believe that Weitzman has an existing issue for this as well. There is also another issue or mailman thread proposing that the url_aliases table be merged into the node table for similar reasons. Let's just invite everybody in, shall we? How is the comment module different from other modules - core or contrib - in similar situations? Should this (inserting/removing fields into/from the node/taxonomy/user/x tables in .install) become the rule of thumb to streamline any queries that result in temporary tables? -K