Why does that come as a surprise to most people? Businesses don't care how their code looks - if it works, it's good enough.

Which is also why changes are discouraged - no need to mess with something that works unless absolutely necessary.

Not the best policy, but if it works - it works :-).

It definitely depends on a lot of factors.

Even if they don't have any formal coding standards, a company can ship good products as long as they have at least a few decent programmers.

Ad hoc / beta testing can fill in for unit testing. Bad coding style and low modularity won't necessarily make a project slower or worse, just harder to maintain. Lack of version control isn't necessarily a major problem if there are daily backups of source code, and if each part of the system is being developed by only one person.

No tech company or startup would ever consider things like that sane practices, but many companies do get away with it. Especially if what they're programming isn't the company's primary product or service, like in the case of a university.

I learned this the hard way. I am the sole developer at the company I work for. I write code for 10 different web products. One of them receives inventory feeds from a myriad of different content providers, and most of these companies (with teams of developers) don't really know the first thing about proper xml design. I wrote a basic framework to do the bulk of the work for consuming their data, but the decisions they made run the gamut from just plain laziness to utter incompetence. Still, I'm not paid to critique their decision making process. I get paid to write the code that makes their data work with our system.

Again performance and security improvements come in at later stage when the business wants the systems to be more cost-effective and performant.