people being afraid to touch the code to avoid breaking a rare and poorly-tested code path
In short, no unit tests were ever written.
Yes, welcome to the real world of software development where deadlines trump other things.
Your concept of the "real world" is pretty damned narrow... and false.
I would reply like this: No. Welcome to the real world where shitty programmers or shitty organizations pretend their shitty practices are the general case.
I've worked in large commercial firms, small start-ups and defense-related companies, each with teams of various sizes and different projects. C/C++, Java, C#, Python and what not. Some where horrid, some were great. Most were ok. Unit testing has always been the norm for the ok and great. Horrid experiences were with the few projects I've been where there was no concept of automated testing.
I mean, shit, good programmers have been implementing their own automated tests in one way or another even before the term "unit test" was introduced in the agile lingo. And normal companies that do not have their heads up their buttholes have plans that take into account some form of testing.
Deadlines always exist, and many times things have to be shipped out without full tests. This is typically the norm for, say, delivering an emergency patch.
But these are the exceptions rather than the norm. And in all cases, you simply put the missing tests on a backlog and re-calibrate your plans for the next sprints to take these into account.
If you are working in a company where code quality always suffer due to dealines, then get a different job somewhere else.
And if *you* happen to be the cause of such mishaps, please get out of the industry. It takes one crappy programmer to deliver poorly tested, badly written code that ends up requiring an army of engineers to deal with it.