Well, there is so many here that I refactor it to better discussion:

1. Almost all legacy does not have TDD. Although TDD is an old technique, published 20 years ago, in practice inside XP for at least 25, it has not being well spread. Thus, we can expect that most of the software cannot be maintained with TDD, although new features can be added with it, but we have to relay in the Refactoring "book". So, you have to go to the second scenario.

2. Almost every TDD practice is wrong. Although there is a lot of software claiming to be built with TDD, it turns out that they have not followed TDD correctly. I learned that almost a decade ago because of the "TDD is dead" flame-wars, all the discussion raised because of the misunderstanding of Unit Test, for ones were the old Waterfall semantics, for the other the Agile one. For example, you say "TDD and no documentation", that is contradictory, well crafted TDD tests are documentation. Without TDD, tests are not reliable, and you cannot refactor as supposed. In this case, you end in the second scenario again.

3. If you have problems keeping the speed with TDD, probably you are not practicing it as it was expected. TDD is so hard to learn for the old Waterfall mindset that Dan North invented BDD to teach TDD. You can learn it from Dan North, or from the original sources. I also have several articles trying to tackle these misunderstandings.

4. About the students, I am also a professor in the university, and yes, the big problem for students is that they always work in green-field projects and never learn to deal with their own mess. Well, all but mine, I give them an existing code and I ask them to practice maintenance for almost three months.

5. It does not matter how wrong is the software, nowadays, I will avoid rebuilding it from scratch as much as possible. Old messy code has countless pearls of knowledge, as much as completely useless behaviors. So best going step by step refactoring it and trying to learn from it, instead of throwing it.