You missed a very important point: What makes it permanent (or at least provides much of the inertia) is the risk of reintroducing old bugs and not wanting to manually test all over again. Automated testing does not have this problem.
In practice, of course, this depends on how badly the testing framework is entangled with implementation details, rather than testing via a public interface. If making changes means having to rewrite 90% of your automated tests, you haven't gained much.
(The article has a couple other potential threads in it, as well, but that seems like the main idea to me.)
Automated testing has less of this problem. It still has the problem that some testing must be done manually, and there is a large spike for code in production.
Good point. I mentioned in another comment here that some languages (like Haskell with its strong, static type system) mitigate this problem. And for languages without static type systems of this nature, automated testing can produce the same effect (which is not to imply that tests for Haskell programs are useless).
In practice, of course, this depends on how badly the testing framework is entangled with implementation details, rather than testing via a public interface. If making changes means having to rewrite 90% of your automated tests, you haven't gained much.
(The article has a couple other potential threads in it, as well, but that seems like the main idea to me.)