The bug listed here is important, both on the theoretical POV and for functional reasons. If table rows are allowed, this leads to different DOM subtrees in HTML and XHTML documents even if starting from the same origin.

<table><tr><td><td></tr></table>

In HTML:

 table
  + tbody (implied)
     + tr
        - td
        - td

In XHTML, where no DOM completion occurs:

 table
  + tr
     - td
     - td

with disastrous consequences in the application of CSS and possibly JS.
Notice that, according to the rules about tag omission for TBODY in text/html, free rows can always be inserted in tables. The difference is that they are "free" only apparently. In valid XHTML, as tag omission does not occur, the document must be provided with explicit <tbody> elements, leading to the same result.

This is a bug that was inherited from XHTML 1.0. (I'm not saying we shouldn't change this.)

It's not only a matter of polyglot documents (which aren't that silly as an idea...), but a matter of spec precision. According to HTML rules, I can insert <tr> elements inside a table, as valid CHILDREN. But this is nonsensical, since there is NO CASE when a <tr> element inside a table is not considered as a child of an implied <tbody> element.
I think we shall get rid of those rules inserted in XHTML spec just because it had to make much of authors' mistakes as valid behaviour. Probably this rule was invented in order to make easier the transition to XHTML for the bunch of tables made "on the fly" and carelessly by authors, 90% of which were made with the purpose of layout structuring. Because I think that where a REAL table is needed, an author will provide the whole structure, with <caption>, <colgroup>s, a <thead> (if needed), at least one <tbody> and a <tfoot> (again if needed).
XHTML is made to have stricter, sensible rules (see the case for <noscript> tag), not to allow unnatural and incorrect behaviors just because "in the wild it is common use".

Right now, this appends a valid table that renders correctly in every browser:

   var table = document.createElement('table');
   var row = document.createElement('tr');
   var cell = document.createElement('td');
   table.appendChild(row);
   row.appendChild(cell);
   document.body.appendChild(table);

Why would we break this?

It violates the DOM Consistency design principle.

(In reply to Ian 'Hixie' Hickson from comment #4)
Such a script would insert everything everywhere, I suppose. Sure I can use it to insert a <div> element inside a <span> element or any element inside a table element. And such elements render as expected.
The rules for determining elements' content model are made for regulating both source markup and scripts. There must be an underlying reason for elements to be placed in a specific way, before the rule allowing it.
What would the use case be for a script inserting the table row directly inside tables, rather than inside table rows? 
(NOTE: Laziness cannot be considered a reason, otherwise things like layout tables should still be allowed).

The reason is simply that there's no reason not to allow it. What's the purpose in requiring <tbody>? It serves no purpose here, so why require it? I'm confused.

By that argument we should also allow <table><td/></table>.

OTOH, the spec already requires the <colgroup> element when there are <col>s, which seems to be exactly what this bug is asking of <tbody>.

The reason for the DOM Consistency design principle is e.g. that you can write scripts and style sheets for text/html content that will also work correctly for valid XHTML content.

For instance, the createTBody() API will result in invalid DOM if the table uses <tr> without <tbody>.

We could allow <table><td/></table>... what's the use case?

The <colgroup> thing is a back-compat mess, IIRC. If we want to change that let's do that in another bug.

The reason we originally had this, I think (it predates the WHATWG) is that the HTMLWG at the W3C didn't want to require that authors add <tbody> elements in their XHTML elements. That reason makes sense to me from a markup consistency point of view; I'm not sure DOM consistency is any more important.

Obviously XHTML isn't as important to us now, but requiring that authors include <tbody>s when they don't really think about them seems to be unnecessarily strict.

From a markup consistency point of view, if only there were cases where <tr> elements are allowed directly inside tables, <tbody> wouldn't be implied.
For browsers tbody is ALWAYS implied, apart from the cases where a script forces tr elements inside tables, but a script could force everything in the same way.
A language consistency ideal framework would suggest that table contain
 - one optional thead
 - one optional tfoot
 - at least one tbody
where each of these elements have all the same content model: <tr> elements.
I think that the argument about unnecessary tbody in XHTML was to validate a de-facto situation, where tables were used out of their context and out of expertise:
 - I need a 2-column layout
 - then I need a table with a row and two columns
 - then <table><tr><td><td></tr></table>
No theory. No rules. No consistency. And no structure.
As of now, the same document in HTML and XHTML is parsed differently and its stylesheets and scripts are applied differently. All this can be solved with the strict application of the rule about thead/tbody/tfoot. If authors want to create usable content, they may keep on using tr inside tables. If they want to create perfectly usable and valid content, the rules should be stricter.

<tbody> isn't always implied; it's not implied in XML and it's not implied in DOM manipulation. Only in HTML parsing is it implied.

Is there a concrete problem with allowing <tr> there? The discussions here seem to mostly involve theoretical problems, but I'm not seeing a real-world issue.

(In reply to Ian 'Hixie' Hickson from comment #10)
> The <colgroup> thing is a back-compat mess, IIRC. If we want to change that
> let's do that in another bug.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25535

(IIRC, only IE implied <colgroup> in the parser, and HTML4/XHTML 1.0's content models allowed <col> without <colgroup>.)

*** Bug 25324 has been marked as a duplicate of this bug. ***

Bug reports like this one are extremely annoying and wasteful and disrespectful of other people's time. Nobody wants this change to be made. It doesn't solve any actual real problem that anybody cares about. It would only create a new large problem that would make a lot of people unhappy.

The proposed change would not be a win for authors in general and especially not for users of the validator. In practical terms, if this change were made, it means that the validator would start reporting the most-common table markup case as an error -- for a case that neither the current validator nor any previous validator have ever reported an error for and that causes no significant real-world problems for authors in practice. Authors would not find that helpful at all, and would not welcome it. Instead they'd just file bugs against the validator, or just quit using the validator altogether.

WONTFIX per Ian and Mike.