I refer to it as "designed by programmers". It's so prevalent that the Silicon Valley TV show used this as one of it's story lines.
When I worked for a consultancy in early internet days I also often repeated "the customer doesn't know what they want until they see what they don't want". People weren't used to web GUIs and there weren't the common patterns we see today, so it wasn't until they had a half working version they could actually give feedback, so getting early feedback was essential to reduce the frustrating of building something that is immediately changed. It still applies today but less to do with usage patterns and more to do with missing requirements the customer forgot to tell you about.
Conversely, I've seen way too many designed-by-designers GUIs and UX flows that can be best characterized as a glittery, polished turd. They sure look nice in Figma but often only have one well-specified happy path from which the end user will surely deviate. Managers will easily greenlight broken designs because they can only see the visuals, not the complete picture.
If you find a talented designer, they are valued so much they will only get assigned to design tasks. If you have a rockstar 10x developer, their mind just cannot comprehend the average 0.1x end user.
What you need is someone who understands design but dislikes it enough to not focus on aligning single pixels or fixing the kerning. They need to be able to code but hate it with passion, because hard-working programmers create software for hard-working end users and the end user is not hard-working.
That's because "UX" designers need to build according to actual usability engineering guidelines, not just built what "looks good". The 1995-2005 feels like it was the golden decade of this sort of thing.
A lot of UIs are made to get a promotion. Others are made by numerical optimization of the funnel, which is even worse. The best UIs come from incorporating lots of actual user feedback, and then it almost doesn't matter if they're built by programmers or designers.
The "one happy path" idea is what you want, though. Non-technical users use software through rote muscle memory (it's why in 25 years as a sysadmin I've had thousands of "there was an error message" reports and precisely 0 of those people actually read the error message to report it to me: not in the happy path means user simply shuts down).
The problem becomes that people try to make software too complicated to have one happy path. This is the road to perdition.
An error message is an automated bug report for the developer. I don't know why you think the user is supposed to care about it, or even see it. Are you paying the user to develop the software?
When I worked for a consultancy in early internet days I also often repeated "the customer doesn't know what they want until they see what they don't want". People weren't used to web GUIs and there weren't the common patterns we see today, so it wasn't until they had a half working version they could actually give feedback, so getting early feedback was essential to reduce the frustrating of building something that is immediately changed. It still applies today but less to do with usage patterns and more to do with missing requirements the customer forgot to tell you about.