I have a hard time understanding this scenario. What kind of content are you working with?
The hypothetical <table-for-layout> element is just not needed in any scenario. It would have been useful back in the day before IE supported display:table, but that is at least a decade ago.
I could just as easily say that the "problem of overloaded operators" only becomes a problem if you try to use + to add anything other than two ints. So don't do that.
But OK, assuming I accept the premise, what should I do instead? The CSS community has been dithering about the answer for years. Only very recently has there been anything even remotely approaching an acceptable solution i.e. a solution that actually reproduces table layouts without having to pile on a ton of hacks. In the intervening years, a lot of legacy code was produced that used <table> for layout because it was the only thing that actually worked.
There also the fact that <display-table><tr><td> or something like that just looks a lot cleaner and is easier to read than <div class=table-for-display><div class=table-row-for-display><div class=table-cell-for-display>. When you make complex table layout you end up with a lot of TR and TD tags, so it makes sense to keep those short to avoid cluttering things up.
You don't really need repeated class=table-row-for-display etc, this can be achieved by CSS contextual selectors.
But in reality html tables was not designed as an all-round layout tool in the first place and the layout algorithm was never specified in detail. Flexbox and flexgrid are typically more appropriate and powerful as layout tools.
I tried that once many years ago. It didn't work. It might work today but I no longer care.
> this can be achieved by CSS contextual selectors
That would be true if display:table worked, but it doesn't (or at least it didn't) and so it doesn't.
And you still need some markup for the contextual selectors to work on. The obvious choice is <table><tr><td>, or, if it existed, <display-table><tr><td>. Maybe <grid><gr><gd> but that's not going to happen.
Can you describe the problem you are having?
But my point stands even if display:table works nowadays. The problem is not what you have to type in order to specify that some piece of markup should be displayed as a table even though it is not semantically a table. What matters is how much you have to type, and whether you have to redundantly specify that a table is for display only on every row and cell. To use display:table you also have to specify display:table-row and display:table-cell, and you have to do it again and again and again and again even though all this information is redundant and only needs to be specified once at the top level. There is absolutely no rational justification for this. It would be as if you had to specify the type of a variable in C not just when it was declared, but again every single time you referenced it.
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.