I've seen the opposite as well: ugly looking terminal or DOS based but very productive software was replaced with spiffy looking windows or web based software that was slightly slower or unable to keep up with the type-ahead of the users and this led to huge disappointment.
I'm firmly believe if it doesn't work it doesn't matter how good it looks and if it works but looks bad that's better than the reverse.
Then once you've figured out what to build you can always make it look pretty.
It's not a dichotomy. I'm arguing for the importance of both, not either-or. Obviously, a thing that doesn't work, doesn't work, regardless of how pretty it might be.
> Then once you've figured out what to build you can always make it look pretty.
That's a lot harder than it sounds. No, of course you don't commission a big fancy design before you know what the thing should do, but you equally can't just build an ugly, but functional thing and throw lipstick on it five minutes before shipping (or after - activities schedules for when the thing is 'done' have a nasty tendency to not happen). Both, in parallel, at its time, not either-or.
Terminal/DOS-based software isn't ugly, it's just a different interface (GUI vs. non-GUI).
Of course some technical people that know what they're doing will enjoy using the command line because you don't have a GUI that gets in the way, but using this fact to "prove" that people like ugly software better doesn't make sense—it's just a bad example.
I worked for a very large corp that wanted to convert an application that we used to process applications. It took less than a second to process 99 percent of applications. They wanted to switch from a cli app to web. I told them they were nuts. We could currently process the days queue in minutes. Sure the company could have loaded all the data and used js to feed them out quickly, but the programmers had no idea what we were doing and certainly wouldn't have designed it correctly. The company wasn't changing it to be trendy, they were changing it to make things easier. It would have had the opposite effect.
Not blind, but I had eye surgery about a year and a half ago, followed by a recovery period about 4 weeks longer than I was told to expect, during which I came to appreciate things like contrast. Not coincidentally, I also realized my software was literally* painful to use for someone in my condition.
I have learned to give a shit about color choices.
*That's the literal 'literally', not the figurative one.
It hugely depends on the target user group: admins don't mind about an 'ugly looking ... but productive software', but non-IT users mind a lot, and for them it has a significant effect on usability. It can only be '_very_ productive' for the target group, when it is also well-designed for them.
I'm firmly believe if it doesn't work it doesn't matter how good it looks and if it works but looks bad that's better than the reverse.
Then once you've figured out what to build you can always make it look pretty.