Because assistive technologies (like screen readers) won’t interpret it as a table, but the browser will, giving you the ease of table-based layouts without the accessibility hang-ups.
At least VoiceOver on Safari uses the `display` CSS property to decide how to describe an element unless you explicitly give an element a different ARIA role in the HTML, so this isn’t 100% correct in practice (although it obviously should be!). [0]
Why do you consider that better? If I understand your suggestion "type=for-display-only" would semantically turn the <table> into a <div>. Why not just use a div in the first place?
Because it's DRY. With the top-level annotation, the rest of the table spec remains unchanged, so if you change your mind and decide that you really want a display table to be a semantic one or vice-versa you only have to change on thing whereas if you used DIVs you now have to change not only the top level but also every row and cell.
You don't decide on a lark if you want some content to have table semantics or not! Tags are selected to indicate the semantics of the content. Content don't change semantics unless you rewrite it to actually be something different.
In any case, you might just as well decide the table was a list item or headline then, right? So you would need
First, one of the reasons HTML has been as successful and widespread as it has been is that mere mortals are able to use it, not just trained software engineers and designers. Mere mortals may not make such decisions on a lark, but they might make the decision incorrectly and have to go back and change it for that reason. Why make more work for yourself than necessary?
Second, making changes is not the only reason to make code DRY. Re-using TR and TD tags is analogous to operator overloading. If you want to add two numbers you want to be able to write x+y and have the compiler figure out whether that means an integer add, a floating point add, etc. You don't want to have to write (say) x II+ y if you want to add two integers, x FF+ y to add two floats, x LL+ y to add two longs, etc. It's the same for table rows and cells. The mental distance between tables-for-layout and tables-for-structure is smaller than the mental distance between integers and floats. It's just annoying to have to keep telling the computer over and over and over again "this is for layout" or "this is for structure" particularly in a case where the number of repetitions can be very, very large. There is no value add in forcing someone to do substantially more typing when the thing being typed contains no additional information that the system does not already have.
> It's just annoying to have to keep telling the computer over and over and over again "this is for layout" or "this is for structure" particularly in a case where the number of repetitions can be very, very large.
I have a hard time understanding this scenario. What kind of content are you working with?
You have it the wrong way round, it's a benefit that it makes it more accessible.
Abled people benefit from a system where their browser considers that div as "table-like" in the way content flows through it. Likewise, disabled people benefit from the fact that their screen-readers consider the div as a simple container without imparting any sort of tabular semantics ie expecting some data organized in rows and columns.
I think they mean to say that sometimes you might want the visual structure of a table but you don't necessarily want it announced as a table via screen readers since it isn't data that's being represented.
[0] https://bugs.webkit.org/show_bug.cgi?id=197786