On a Mac, this is configurable. The article talks about this, and about respecting user configuration when possible.
I mean, if I write an app and hide a "dysfunctional prettiness [Y/n]" configuration somewhere in settings, is that a good thing?
I'd argue there are at least two better options that are trivial to implement, and surely more if one cares to do UX due diligence when trying some novel design.
Wasn't your original complaint that someone decided what was "better"? Or are you complaining that they didn't take your choice? Point being that someone that decided otherwise thought they had a good reason for their decision, too. In this case, it could be argued that trackpads reduce the need for the scrollbars. (I have no idea what the real argument for such UI behavior is.)
In my experience, the backdrop in many of those cases is that UX changes get rolled out because people need to justify their jobs or they think X is prettier/popular. You don't hear nearly as much about people doing UX research as you do of people cranking out React things, and it would be extremely benevolent to assume developers do in fact do expensive, time consuming UX sessions w/ users.
If we talk specifically about scrollbars, maybe a good litmus test is this:
- if the default was no scrollbar whatsoever, would that be a problem for you?
- if the default was a read-only scrollbar (e.g. it merely reports whereabouts in the page you are, but does not respond to mouse events), would that be a problem for you?
If the answer to either of those is "no", you probably aren't actually using it. They could conceivably be configurations too, but why?
Consider this hypothetical parallel: why not hide the "Help" menu item in apps? Personally, I don't use it and it would clean up the UI, so it must be fine, right? Well, not necessarily. Because if you bother to do UX sessions w/ users, you may find that people looking to use that specific feature will have expectations about where it should be.
In 1990, everyone scrolled up or down by clicking little buttons at the ends (or at one end) of the scrollbar, or by dragging the scrollbar up and down. By 2019, these buttons are unnecessary and have been removed, and the main purpose of the scrollbar is to passively report the position in the page. Dragging it up and down still works, but few people bother.
But honestly even then it’s not common for me to run into those. I’m a keyboard user, so the thing I get persnickety over is whether or not you got your focus order right, if you steal keyboard focus senselessly, or if you made a UI that only responds to mouse clicks.
Scrollbars are a tool and they should be functional: visible, properly sized and interactive. It helps if a scrollbar looks and functions the same on all our content, because it takes less mental strain to use.
It may be that you don't like scrollbars for your content. The obvious solution is to make your content fit so it does not require scrollbars. If you cannot manage that you will have to live with the fact that scrollbars are there as a functional tool and make sure it is kept functional. In analogy: If I sell furniture you have to self assemble I can choose to design it to not require tools. If it does require tools I should make sure people can actually use those tools to assemble and not try to hide that tools should be used by pretending the thing to put nails in is not a hammer.
With Mac they can generally influence the scrolling interface by making one of the best trackpads and magic mice standard, where scrolling is a critical part and not an afterthought, plus lots of visuals showing how to scroll with it.
You really don’t need to click and drag the scrollbar very often if at all. Especially for page scrolling which the article explained - it’s more important for overflowed objects, especially horizontal ones. And if you need to scroll there’s no guarantee that having 25px control design vs 50px (guessing) like windows would help, the click area tends to be a wide as the bar part not the control.