When I finally decided to really decouple and mock dependencies and create "pure" unit tests was the major "Ah ha!" moment of TDD. I had been trying it out here and there but never really saw the benefit because I wasn't really creating nice testable units.

It is hard to say for sure, because the author doesn't give any specifics but wording like:

"You therefore are more reluctant to make large-scale changes that will lead to the failure of lots of tests. Psychologically, you become conservative to avoid breaking lots of tests."

make me think the author wasn't actually making unit tests, instead they were likely end-to-end tests, or partial ETE tests that were running inside a unit test framework. I have had many disagreements with other developers that just because your test runs inside a unit testing framework doesn't actually make your test a "unit" test.

If you move functionality around between methods, or combining, breaking up methods, won't that mean fixing all those unit tests?

Sure, and that fixing is the process of making sure that the code still works, and that you still have the test suite as a second client of the code.

As with everything there are costs and benefits!

A lot also depends on the quality of your tests. If the team doesn't care about test quality or doesn't know how to write good tests, you can easily get these big blobs of incomprehensible and tedious tests...

It encourages dependency injection, which in my experience will eventually encourage a functional programming style since there's so little barrier to it once you're doing things like injecting the current time into a method which makes use of it. Maybe I'll turn around in five year's time and regret saying this, but I've never regretted pushing a project in a functional direction.

Surely the value of functional style depends on language. Some languages have better guarantees that support functional styles.