Well, look at it this way--what benefits are there in doing so?
- The test suite runs faster
- Less time is spent maintaining the test suite
The argument wasn't whether tests should ever be deleted, but rather an encouragement to delete them as soon as you feel confident in your code. Personally, if a test is still relevant then I will maintain it until the behavior it's testing is no longer part of the application. And often that's a zero sum situation, because now you need to test the some new behavior.
A failed test is literally your test suite saying, "Remember this part of your application that you promised would behave a certain way? Well, surprise! It doesn't behave that way anymore." There is value, if nothing else, in knowing what the implications of a change are, especially as the system grows. So even if you're okay with a change in your application's behavior, I'd argue that tests are the best way to be aware of what those changes are.
A huge benefit of deleting tests isn't merely the reduction in maintenence but the reduction in "conceptual drag". Tests cause design decisions to get baked into code to a higher degree than if the same decisions were made in a codebase without tests.
Tests certainly can be valuable for verifying the scope of changes, but they're not the only way to do this. I could imagine supporting the process of delete-as-you-go testing if you could convince me that whatever you are doing to identify regressions works just as well as the test suite would.
I'm not sure you can separate "identify regressions" and "test suite" into different buckets. I'll concede that if you can, it'd be an acceptable replacement--assuming, of course, that it doesn't add more friction than it replaces.
- The test suite runs faster
- Less time is spent maintaining the test suite
The argument wasn't whether tests should ever be deleted, but rather an encouragement to delete them as soon as you feel confident in your code. Personally, if a test is still relevant then I will maintain it until the behavior it's testing is no longer part of the application. And often that's a zero sum situation, because now you need to test the some new behavior.
A failed test is literally your test suite saying, "Remember this part of your application that you promised would behave a certain way? Well, surprise! It doesn't behave that way anymore." There is value, if nothing else, in knowing what the implications of a change are, especially as the system grows. So even if you're okay with a change in your application's behavior, I'd argue that tests are the best way to be aware of what those changes are.