> do you really think "everybody else" would have discovered the actions described without any sort of help page?

No, the article is completely accurate about the lack of discoverability of those features. It highlights them because they are a direct contrast to nearly every other interface feature on iOS. That's what makes them interesting to interface designers.

> I think the modern software does not come with the manuals because it simply has severly reduced functionality compared to the old days.

Oh?

> For example, when was the last time you had used a navigation software with "avoid area" and "add custom road" features?

Did those navigation applications offer traffic overlaying satellite imagery? Public transit directions with real time vehicle tracking? Were you able to just type an address as we parse them or did you need to enter it in some weird little-endian order? Density of people at any given location, how many people are on a bus, or how busy Home Depot is? Up-to-date business hours? Alternate routes on regional rail and airlines? Up-to-date road closures even for temporal events? 3D photographic street-level POV navigation? Terrain maps? Cycling instructions? Weather? Descriptions of area attractions with an array of photographs for each? Wildfire maps? Hail you a ride share?

The number of gained features dwarfs the number of lost features by an order of magnitude in software lasting that long.

> There was always a tradeoff between "more features thus more UX complexity" (power user approach) vs "cut features to keep UX simpler" (UX designer approach).

You're wrong. Our software today does vastly more than software of yesteryear. Most of it feels so natural-- like those maps features-- that you don't notice it coming into existence. It just sort of fits right into the ecosystem-- and that's the whole point.

FOSS is a perfect example of what happens when software interfaces are assembled by developers rather than designed. I've been a developer, mostly towards the back of the stack, for a good 11 years. I also have art school education in interface design. Most developers have no idea how little they know about the way people use interfaces. To us, a GUI is a visual wrapper that facilitates interacting with the underlying software, like an API. Obfuscating functionality when it's not likely useful seems wasteful to someone used to reasoning about complex software. The problems arise when they take their personal usage preferences, assume they're representative of all users, and treat them as broadly applicable maxims in all of the software they create.

Most users don't have the mental models in place to reason about the software functioning behind the interface-- to them, the interface is the software. An interface that doesn't consider what users need to and almost as importantly, don't need to see at any given point is confusing. Confusing is bad, so to them, the software is bad. To a developer, a confusing interface is something to be overcome by reading a manual.

For example, you'll regularly catch professional photographers kvetching about the cost of adobe products... they have almost all tried Gimp but nearly none of them use it. There's little photographers (vs. say, graphic designers) can do in Photoshop that they can't do in Gimp... so why don't more photographers use it? Because it was designed by developers, for users who already have a mental model of the way software works with little regard for everyone else. Literally the only people you see advocating for Gimp are more FOSS fans than artists. Ask photographers why they don't use it and they'll mention the same things every time-- the interface sucks. It's confusing. Things are in unexpected places and function in unexpected ways. Affinity Photo, on the other hand, is starting to get a following.

Photoshop is far from simple, but both the new user experience and the overall capability vastly surpass Gimp. That's why Adobe's userbase grows by millions of users every year despite direct competitors and people having complained about the price since they released v1. Software with expert users will either accommodate expert workflows or they'll no longer have expert users. Software with new users will accommodate beginners or nobody will adopt the software, if there's competition.

Inkscape, on the other hand, enjoys a decent-ish reputation among professional vector graphics artists and unlike Gimp, is sometimes considered a viable tool of the trade. Illustrator and other tools do a hell of a lot more, but people don't roll their eyes when someone brings it up as a FOSS alternative.

Design vs functionality is a false dichotomy. The fact that so many developers assume complexity in interface == good functionality is the reason open source alternatives are alternative rather than the standard.

> Sadly, the designers won.

Your misplaced blame betrays your lack of understanding of what interface designers actually do. Only managers controlling the purse strings want software to do less. Designers are perfectly happy doing the hard work of figuring out the best ways to communicate software's functionality by what is shown, and what is not shown, on any given screen.

Could you imagine people with different domain expertise, like health insurance claims, designed the interfaces around people with their level of familiarity with the underlying systems? What would you say when they scoffed at your lack of sophistication when you refused to crack open a 400 page manual to file a simple claim? After all, it's right there on page 288 in the manual! How do you find it? Just look for 'adjustments, claims' in the index! How would you know to look for that term? "Hhhhhhhh... you don't deserve to have that claim filled!"

Hyperbolic? Sure. But you shouldn't need an existing mental model of the underlying insurance claim machine to file an insurance claim, and that flavor of contempt for users not already understanding "how software works" is endemic in software development, and exactly what designers mitigate.