Different types of tests. You can have tests of the whole system which should always pass. Then there's unit tests, which may have to be removed/updated (though again, this depends on your scale of units). Some you expect to fail after a change to requirements get incorporated. Others you expect to pass, and you react accordingly.

If the code is designed following the single responsibility principle, and tests are written to test behavior rather than implementation details, then each requirements change should only affect the tests which specifically test for the behavior which changes.

That's still a very narrow view of changes; the belief that you can isolate every part and that requirements changes would then only affect those isolated parts seems is pure fantasy.

I've had to completely redesign entire subsystems; break down components into different pieces; move code between different layers; etc.

Honestly as a manager nothing bothers me more than developers who try and patch complex changes into existing systems without re-thinking how it affects everything else. I have to re-factor a project that's a total mess because code was added but not removed or changed over the course of some very big requirements changes. I'm sure all the tests pass but it's impossible to follow now.

The problem with unit tests is it adds an extra layer of friction on making changes that benefit the product. You are actively discouraged from changing your design from your initial assumptions! This change friction can be seen as a benefit if you need all your interfaces to be stable (like with a library). But it's a trade off and it's not appropriate everywhere.

Yeah you can have bad architecture with or without tests, having tests does not mean you don't have to think about design! I disagree that tests lock you down though, it really depends on how they are written.

You can't have unit tests that don't lock you down to a particular structure of units. That's really the definition of unit testing.

I'm not saying anything about bad architecture. You have a good architecture for today's requirements that is a bad architecture for next year's requirements. Tests lock you down to whatever your first architecture is.

I tend to avoid the term unit-test since there is some disagreement about what "unit" mean. Some think it means testing everything down to the level of individual private methods. This will indeed lock you down. And if it paired with extensive "mocking", where you only ever test that method A calls method B when invoked, then yes, you have locked your self down and you wont get a lot of value from the tests.

I prefer automated tests of larger units or subsystems, and testing against requirements, protocols and specifications rater than implementation details would change. Of course anything will change over time, but I believe this kind of tests provides higher value and lives longer.