It is not fun to pull out the power tools on a huge piece of software with 50 thousand unit tests and see that 600 of them fail because you changed an important part if the code.
It means the unit tests will have to be deleted, and or updated. If each takes 10 Minutes that is 6000 Minutes.
On the other hand, seeing one unit test fail in another module you didn't expect to fail can save you a week of work, so it's all in how brittle and organized the tests are.
In my experience, it means that you have to treat your tests with nearly as much software engineering respect and prowess as your real code. You have to factor things out and try to avoid DRY (particularly tough sometimes in testing) as much as possible.
If there is one "concept" that you're asserting in your test suite, you want that concept to only be repeated once or as close to once as you can get. Often times, people copy paste sets of assertions that have mixed concepts. Then, when a requirement changes, hundreds of tests end up having to be updated.
This is why many large companies, that contract out test automation development or train manual QA people with enough programming skills to write tests, end up with brittle test suites. One look at those test suites by an experienced developer and it's no wonder: there's conceptual/semantic duplication everywhere.
It means the unit tests will have to be deleted, and or updated. If each takes 10 Minutes that is 6000 Minutes.
On the other hand, seeing one unit test fail in another module you didn't expect to fail can save you a week of work, so it's all in how brittle and organized the tests are.