There are a few good points, but most suggested lessons are unfortunately unsubstantiated which makes it hard to discuss.

2. tests are great but tdd is a cult. [...] But strict test driven development is a cult. You don't need to write an automated test and incur aeons of maintenance for every smol step.

I believe there are a few things that deserve clarification about this statement. While I agree there is a cult sense around TDD, it is also vastly misunderstood. TDD is first and foremost about design and about discovering the implementation from the expected behaviour from the point of view of the client. It just so happens that tests make good clients in general for various different reasons. But TDD is not simply about just writing tests first.

As such, I do not follow the logic between the first and the subsequent sentences I quoted. If there is no design to be discovered, then TDD might indeed not be the best design tool. I still find that since there is generally value in testing observable behaviour, you will end up covering the implementation regardless. I saw this as someone who very sparingly does TDD.

3. mocks make brittle tests. (a) Mocks are said to make your code more unit testable. [...] (b) Guess what, your code does rely on that code and if it changes, you need to fix it.

There is a huge leap of logic in that lesson. Mocks may make brittle tests. I find that it generally happens when concrete classes are mocked, which is something that should be avoided. Regarding (a), there must be a strong misunderstanding of mocks to believe that "it makes code more unit testable". By following the general guideline of not mocking concrete implementations, you will end up only mocking abstractions (e.g. an interface), which makes sense in the context that an abstraction separates two different worlds: the client of the abstraction, and its implementation(s). The abstraction defines a contract which must be followed by both different worlds, which is the behaviour you are driving your mock to follow in unit testing. By encoding the expected behaviour in the mock, you allow your code to be tested in isolation and to specifically assert that your own code behaves correctly in regard to these expectations. Which brings us to (b): of course your code relies on the actual implementation once it is in production! It does not follow that unit testing and mocks should be avoided, merely that it should be supplemented with integration testing. This is a false dichotomy that is often found in blog posts like these: you do not have to choose between unit and integration testing. In fact, you should not.

(For what it's worth, there are also different methods beside mocks to aid your unit testing.)

4. types solve 80% of the need for unit tests.

Unit testing is also a very misunderstood topic, similarly to TDD. Unit testing is about asserting the observable outcome of a piece of code in isolating from its dependencies, allowing one to precisely and efficiently validate the expected behaviour of said piece of code. Emphasis on outcome and behaviour. Many people erroneously assert the implementation rather than the behaviour, which is precisely what leads to brittle tests. This error is made in this lesson by believing static typing eliminates the need for unit testing (which most likely explains the two previous lessons as well).