15 years ago almost nobody was using unit tests running automatically on a continuous integration server after each source control commit, and packaged ready for a 1-click deploy. Now I would regard it as mandatory.

I agree that unit testing is something that is much more popular now than it was 15 years ago, that is widely useful, and that is supported by real evidence of its effectiveness.

On the other hand, 15 years ago almost nobody would have assumed that merely passing a suite of automated unit tests was sufficient to guarantee acceptable quality, or that diving in and refactoring arbitrarily was necessarily safe just because a unit test suite existed, or that all software was suitable for instant deployment. Today, how many projects don't really even consider alternatives and just assume unit testing and rapid deployment is the way to go, even proudly telling potential new recruits about how the project pushes code into production every few minutes and new starters will be committing code on their first day?

Unit tests are great, but they are only one tool in the box. There's a whole spectrum of tools from more expressive type systems up to formal proof methods that is orthogonal to unit tests. Maybe a project also needs manual integration testing with external services or real equipment; after all, a unit test that depends on a test double can only be as reliable as the test double itself. Sometimes you simply need manual inspection of results anyway; to my knowledge, no automated tools yet exist that will warn me about a Chrome 97 rendering bug that hides the "Buy now" button on my e-commerce site because I used the wrong 5 CSS rules in combination. There are numerous ideas about how to perform code inspections and walk-throughs, and ample evidence of their effectiveness despite their relatively unpopularity, not least because minor errors of the kind these inspections often find but unit tests often miss cause a substantial proportion of bugs. I do worry that the emphasis on unit tests today means too many people in the industry neglect alternatives that could serve their particular needs as well or better.

Likewise, 1-click deployment is great. However, you can't just package up and 1-click deploy the navigation software for an ocean-going liner that is 50 miles off-shore, or the control software for a microwave oven you sold last year, or software that will run in a secure environment where you literally have to go through an airlock past armed guards to gain access and you have no external connectivity at all once you're inside.

Completing the triangle with these ideas is often the argument that your software should always be ready to deploy and every commit should take you from one useful version to another. Again, this is great if you're lucky enough to work in an environment where it's true, but in the real world this may simply not be up to the software developers. A project that meets 90% of its original requirements doesn't necessarily have 90% of its original value to the customer, and won't necessarily bring in 90% of the revenues to the developers. It might not be possible to add a required feature in a series of small, self-contained commits, at least not without jumping through all kinds of hoops to artificially synchronize different parts of the system or have the code in but not actually running anyway, in which case you gain no advantage from early merging anyway.

Maybe you could make software that works without any of those, but would you want to?

I can and do, sometimes, for exactly the kinds of reasons I mentioned above (well, except for the armed guards one; that was a project someone I knew worked on, but not me personally). Every project is different and has its own requirements.