There are some great answers out there and I would like to throw in my two cents on the subject as it is a very relevant issue I often think about, or discuss with my colleagues. There will inevitably be some overlaps with parts of existing answers, I only hope that I can give a slightly different perspective in those cases.
I have done applied maths as my major and did my masters in biological & medical modeling (whatever that means). I am past half-time on my PhD studies in bioinformatics and systems biology. I almost exclusively work in silico and have come to sire many of those monstrous, ugly and sad pieces of software.
First off I think you are making a small but important mistake in framing your question. You say:
"Why do many talented scientists write horrible software?"
I would instead suggest
"Why do software written by talented scientists end up being
The difference is subtle but essential for the rest of my answer. After all it's not like scientists gather around a table and decide to write horrible software.
Many scientists who write code are not educated to write software
There is a serious difference between knowing how to code versus knowing how to write software. I did almost as many courses in the CS dept as I did in maths, during my undergrad and masters, so I felt pretty confident with my programming skills. That is until I was faced with questions like packaging, dependency management, lifecycles, licensing etc. None of these were remotely within the curriculum during my studies. I don't know if those who do CS as undergrads learn these concepts, but I sure as hell never needed to until I all of a sudden had to know them.
Bosses/supervisors of many scientists who write code are not educated on writing software
Not only do you need to learn a bunch of new stuff, but imagine you cannot explain why that is important for you to learn that stuff to your boss. I have this issue pretty often, as writing code is often held comparable to doing labwork at our department. People think writing code just happens on its own and preferably quickly. I have often had discussions with colleagues where they jokingly mentioned that all they want to hear from me is "computer say yes/no?" How long something new might take is very often underrated, having to write tests continuously is typically seen as a waste of time. Which brings me to my next point....
Good software is not valued in academia, at least not in the same way as industry
The measure of competency in academia is publications, and the form of currency is citations. You are constantly in a form of competition to come up with something new and useful, and only the first one out there will get the prize. Clones do not exist or survive particularly long in academia. In contrast, in industry you can win market shares by better advertising, cooler GUI or lower price. In academia, if some method is already published, you need to do something else.
Similarly, if you have already published a method then additional features, clean-up, optimization etc of that proof-of-principle software is often not good enough to warrant a new publication, which practically means that you have wasted months of work for nothing. Sad but true...
Expectations change, you got to expect the unexpected
Might be a small point but I can't stress it enough as it has come to bite me in the back over and over again. You simply don't get proper specifications for a new project. They are often either all too vague, or way too strict (unrealistically so). At times, something that wasn't ever mentioned turns out to be implicitly expected. Then to add insult to injury the specifications change based on a new data format, some other database, new features or just that other cool thing the boss was thinking about when he was away on a conference... You write and rewrite solutions to the same problem, it becomes a clutter.
You typically don't get the support you need
The few programming PhD students at my dept we try to improve ourselves by keeping up to date with the trends. Learning best practises for instance via SO. But more often than not when you want to try something new you see hinders; either the IT dept thinks you are too much of a nuisance, or the boss thinks you are slacking off, or the people you are asking help from think that you don't know sh*t and you are wasting their time. For instance it's taken me several months of negotiations and mailing back and forth in order to be able to access our version control server from home. Eventually it just works faster to skip certain best practices.
The newest coolest CS trends aren't always well documented for people who are not experts
I have tried to get my hands dirty with several "new" technologies, which often have some steep learning curve. Sometimes it's really not worth the effort. Best example I have is Maven. As I often work in Java, I thought I should use modern tools for packaging and dependency management. But my conclusion, after having battled with it for so long, is @%&$ it! I really don't have the energy or time to go through that mess of a documentation.
After giving myself grief over these in the past years, I came up with the following conclusion which gave me some inner peace:
"I am not a software developer. I am neither educated nor paid to write software. Writing software is not my job; learning to solve certain problems is."
Hope this answer gives you some insights as to why software written by scientists (exceptionally talented or otherwise) often don't live up to the standards established by software developers.