Wrong. Tables impart meaning to user agents (browsers, screen readers, google bots, etc) and as a side effect they have a default visual style that is useful for some layouts in some limited situations (but without any kind of fine-grained detail that most modern designs call for -- ESPECIALLY when making responsive designs that work across different screen widths).
CSS Grid, on the other hand, is a tool specifically for complex visual layouts which imparts no semantics on the content (so it is proper to use for non-tabular content).
It's worth trying Inventor (or Autodesk Fusion 360, which is basically a cloud-based Inventor with a free demo) to see a constraint system with a good GUI. Draw lines and make boxes, and if you end a line at an edge, the line endpoint is constrained to that edge. End a line at the endpoint of another line, and those points are constrained to be at the same place. If a line is drawn vertically or horizontally, it's constrained to stay vertically or horizontal. Drag a point or line, and everything else is adjusted, but as little as possible, to maintain the constraints.
Specify that two lines must be parallel, or perpendicular, or the same length, and those become constraints. Specify a dimension between two lines or points, and they stay that distance apart. A dimension can have an expression based on other dimensions, so if you need something to be twice the distance of something else, you can do that.
This goes beyond straight lines. You can have a circle or arc constrained to touch a line or another circle or arc. A curve can be constrained to be tangent to something else, for a smooth transition. Designers would love that.
The GUI won't let you add a constraint that conflicts with another constraints. There's no "constraint priority". All constraints are equal.
The GUI has a counter which shows how many degrees of freedom still need to be constrained.
Little red arrows show you what can still move. When everything is constrained and nothing can move, the counter changes to "fully constrained", and the sketch is now rigid. But you don't have to go all the way to fully constrained if you don't want to. The system will do something reasonable if you don't.
Some sketch dimensions may be driven from another sketch. In the web world, this would correspond to adjusting to window size.
The CAD people deal with hard geometry problems, much harder than the ones web layouts face, and they have much better technology for doing it. It's even user-friendly.
Disclaimers: I'm not principally a UI/UX designer, though I (re)write a hell of a lot of CSS because so much of it completely sucks.
Tables overload what should be a data-definition element with layout semantics. And, yes, there's an argument that might be made, I suppose, that Grid (which I'm only just learning of from this video) might recreate some of the sins of table-based layouts. Especially of "pixel-perfect" layouts.
And, yes, I can see clients or frameworks which, say, assign a grid to Every. Damned. Paragraph. In. A. Page.
You cannot out-wit stupid, it's far too smart for that.
But the positive here is that you're getting the gridding of tables with the flexibility of semantic positioning. And that could be useful.
And unless you're dealing with a truly supergenius-level idiot, you might be able to deal with broken Grid layout by just dropping the Grid-based CSS entirely. Tools such as Reader Mode or Pocket (or similar) should have an easier time parsing this sort of thing.
Though really, if you want to fix HTML truly, insisting on standards-compliant formatting and imposing a penalty (Web search still seems to be the gatekeeper role here) on Really Bad Design might address some of that.
Though there's a horribly large amount of Very Bad Structural Page Design. Including much of it from, oh, just to select a publisher at random: Google.