X4: Foundations would be a good example in games. It's often not so much how any individual design choice is made, but how those design choices shift from programmatic context. In X4 look how basic persistent interactions are distributed such that you have to dig through multiple places to maintain the same handful of controls. For a hyper specific example in X4 try to assign a captain to a ship. That alone is the end of the road for a minority of players. Some people (me), even after figuring it out, will forget and get stuck later when they are trying to do the same thing again. Usually it's more about the distribution of controls.

Often you can see it in the distribution of game achievements achieved by users. More obtuse approaches will have a higher early dropout rate. But the people that get through it will get a higher relative rate of late game achievements. Resulting in an achievement rate that is lower but flatter in the percentages of people that achieve it.

In past years there was this inclination to try to simplify the UI to avoid confusing a hypothetical Grandma. This was generally disastrous. It took away front facing options that frustrated regular users, and was completely irrelevant to someone like my mother who continually got lost on how to find the internet on the big blue button on the taskbar. Yet understood single/double-entry spreadsheet entries perfectly, faster than me.

Context is too varied for hyper specific examples of what you understandably asked for to be meaningful. Because consistency across context is king, extensibility is queen, and consistency is the child. Which makes hyper specific examples sound like I'm being obtuse with my expectations. So I think the best way for me to go about this is to describe my file protocol handler and what kind of tradeoffs I made for programmatic expediency.

I initially called this program Drawers (later just Q). With user defined command line switches, it essentially allowed me to turn every taskbar shortcut into its own private user defined start menu. It displayed more like a fancy context menu, and exited immediately after use. And because each file type had its own editable default drawer, and every 'file' opened with this app, I could get the same options available from double clicking any file anywhere that was available from the taskbar, or anywhere else. Every app on the computer, or any command line string+switches, could be included in the default choices available in any given Drawer. These Drawers also included Run/Compile for various programming languages. So those old programmers text editors with limited run options merely needed to be pointed at Q to get a complete range of standardized options. It even properly redirected stderr/stdout etc. There were special characters in the config that would force stdout et al somewhere else if defaults weren't sufficient. I even wrote a pure shell script version that ran entirely in a terminal as practice for getting the Linux specific features figured out.

I was initially happy with manually editing an inifile structured config file. But when I decided to extend this and add this functionality to the UI is when I started making choices for programmatic expediency. I added the ability to configure Q by sorting Windows shortcuts, and/or Linux desktop files, in subfolders of Q. It worked seamlessly with the inifile. It was overkill, but I was experimenting with options. The issue was that implementing drag and drop went over my head in the programming language I was using. Initially AutoIt, later Python /w Tkinter. So I implemented a cut/copy/paste scheme. There was also a right click and edit specific key/value pairs UI. It required the same understanding of options as manually editing the config file. But shortcut Drawers had a default option to add its command to a specific Drawer. To open a Drawer(s) in edit mode required the Ctrl key, so you could copy/paste between Drawers. Since the UI only updated with a restart, an edit mode command line switch was added. So it restarted with every change made.

It was functional, and in some way elegant, even if a lot of the overkill could be removed. And it made my dumpster diver built computer with Linux far more responsive. But for a mass audience those configuration options would have been a complete mess. Even for me, with intimate knowledge of its internals, choosing how to go about making a configuration change was obtuse. It was easier just to open the config file directly, or the file manager if I wanted to reorganize a large number of Drawers. Fundamentally unfit for a mass audience. It would produce an endless torrent of obtuse questions from users on various forums. Or just getting deleted and forgotten if the defaults weren't compelling enough. It was, however, on par with a lot of choices programmers make. For essentially the same reason programmers make those choices, for expediency.

But for my own limitations it didn't have to be this way. I can define the drag/drop functionality required to overcome these user issues. But working backwards from the UI functionality to the programming choices required to achieve it isn't easy, even with better skills than I possess. And specific choices are going to have tradeoffs that I can't predict beforehand. Just because it seems perfectly reasonable and elegant to me means nothing to a mass audience. An audience that isn't (generally) going to take kindly to being required to solve a de minimis puzzle. An audience that typically gets confused about the distinction between a server and a client. Just because someone can understand doesn't mean they should be required to repeatedly willy-nilly. I do not like being required to unnecessarily revisit even minor puzzles, or even to be forced to fetch a keyboard unnecessarily. Why would I expect users to be any different?

The child, consistency across context, is the key to achieving that. Not by removing options. Or hiding it like some obscure condition hidden on page 63 of the ToS.