Tables of a static size, or small dynamically generated ones, are fairly straightforward because you just pay the entire cost of layout upfront. The layout algorithms themselves are a feature farm - CSS is complex because it supports so many ways to do things across a multitude of assets. If it's something like a game GUI, the layout can be bespoken to a particular stylistic choice and specific asset types. It's still not a trivial endeavor(headaches always abound when trying to align graphical elements in a top-down composition), but more of the programming load goes to text rendering, selection and input than layout once you drop CSS-style flexibility.

Lists and tables with both dynamic sizing and scalability requirements(think the "infinite scroll" style of presentation plus insertion and removal of elements plus nesting plus accordion folding) create all sorts of challenges in trying to amortize the processing costs. That's where layout code can get really out of hand.

However... if you opt to paginate by a fixed element count, most of the challenges go away because there's only so much layout you can fill a single screen with, and that lets you revert to brute force. At that point it's a question of "OK, how much scrolling do we need?" Scrolling itself has gained a reputation for being mostly detrimental to UX, so in terms of cost-benefit for productivity it would be one of the first things to go.

In a lot of ways frameworks create the problem for themselves by trying to do everything.