Another important consumer-end feature of splitting style/structure is it allows clients to have custom styles, accessibility-oriented styles, by just swapping out the "styling" content of an application/page without needing to swap out or inject into the UI structure/code.

The benefits to developers are more "trade-offs", but I think it generally is a better raw framework to work in without significant IDE-assistance to do development.

This is an important feature that, statistically, nobody uses. Worse, I challenge you to try it on a major site. :(

Again, I like the argument. I just feel there is more taking about it, than benefits from it. Empirically, it just falls flat.

You are probably right. But also statistically, "nobody" is disabled or needs accessibility features. That's a poor argument for running in the opposite direction from providing them.

Benevolent systems cater to the least powerful user, not the median user, and I think it's good to support benevolent systems wherever possible, because businesses are naturally biased against benevolence.

I challenge that. There are fewer disabled users, true. Statistically, they do exist. They far outnumber folks that use this feature.

> don't actually have that

Not clear what exactly.

> with just minimal styling and/or multiple versions.

If an application has simple UI that can use predefined and quite limited set of system UI elements then you probably don't need to style anything. But this is not the case of the library we are discussing.

Apologies, keeping things brief on my phone often backfires.

What I meant is that most of us don't have the same content that needs to be styled differently across different devices. Majority of the time, things are easier. As you mention, use the predefined UI elements and call it a day. It is sadly hilarious how much better that would be for most applications.

For things that do have content that wants custom styling, think games and such, you are almost certainly either inventing your own abstraction language and porting that to different targets, or just creating a new implementation for each target. Yes, some folks have tried to make uber languages where you "write once, run everywhere." Those are almost always subpar compared to "write once for everywhere you care about running."

I'll say that I do agree with the argument on its merits. However, I disagree with the argument on evidence. Statistically, the style/content divide has really just increased the complexity of the code I deal with.