I am sure I could discover an equal "simple" example that is easy in CSS but difficult/impossible in GTK.
That you cannot use a hammer in the same way as a crowbar, even though they are both blunt instruments, is not a condemnation of the hammer. So yes, you do need to evaluate what the right tool for the job is - like JS to do a quick width-match on the labels' natural widths - after the CSS did most of the rest. That is not "bla-bla-blah," that's just knowing the limits of your tools.
The frustration seems to be the impression that CSS should be able to solve any conceivable layout desire on the web, which isn't its charge: CSS is first and foremost made to style web documents, which by-and-large don't fit as easily into the constraint-based-layout box as a traditional desktop app would. Since this kind of desire often crops up in desktop-like SPAs, where JS use is endemic already, it's not wrong to use a little bit more JS to nudge the visual experience a little closer to what you'd see on a desktop app.
I guess my takeaway is, CSS doesn't promise the world, so if you come in expecting that, you'll walk away disappointed. Luckily there are many tools in the web dev toolkit to achieve your engineering desires, and it's not verboten to use them (aside from a philosophical desire to avoid JS, but if the biggest problem for your page when JS is disabled is that the labels are slightly different sizes, I think you're doing a great job already).
I am sure I could discover an equal "simple" example that is easy in CSS but difficult/impossible in GTK.
I doubt it, really. I mean, you could find something for base gtk (which is already out of reach compared to css in ui geometry, because it was done for it), or for the fact that gtk is not a networking engine, but it is just a bunch of predefined containers, calculation phases and signals in C. It is easily extensible in a native way and hides no knowledge about how everything looks or works. Gtk is an example of how you expose distinct particles, pre-implement few useful combinations, and then users build a universe with them. Css is an example of ritualistic black box that hides almost everything about its geometry and requires a non-trivial effort for really basic things. E.g. in css, you have to struggle with dumbest things like a one-pixel vertical scroll in a single-line input. My complaint is not "css is not gtk-like", it is "css is incomplete and unreasoned AF in its own model".
I don't think we can have a reasoned discussion about this if you're going to write off any contention as "bla-blah," so I'm disengaging.
Their knowledge of CSS is built from a set of "how do I do X in CSS" searches
Because "box model and selector specificity" is light years away from how to do X. If you want an analogy, you are suggesting to win a chess tournament by thoroughly learning chess rules and figures. But you can not. It is okay for chess, where you build up your expertise for years and decades, but not for a rapid application development. Css is a bike with no front wheel, one pedal and it only turns left, unless you know that sit-backwards hack. There are better (more reason-enabling at least) layout systems out there, but cool web guys are digging in their heels on that "css" thing. And that would be okay, iff they made that damn bike at least complete, at least once in its lifetime.
Want a simple, trivial puzzle?
Make all labels of the same, non-fixed width, for these forms to look more aligned under different label localisations. Without recomposing layout elements. In constraint-based layout, it is a.w = b.w = c.w (priority:low). In gtk, you add (a,b,c) into the same SizeGroup. In css I'm doing it the wrong way, these requirements are strange, I should rethink my model, take a different/better approach, maybe it is okay for them to not be aligned, because awesome css at least solves a huge load of problems and the internet rests on it, bla-bla-blah.That even may have an almost-css-only solution, but whatever it is, it will be yet another "recipe" with a pile of crutches as ingredients. Which is likely not compatible with rendering loops or a structure of a half of popular js/css frameworks.