I love the series (and the "wat?" talk, of course - somewhat less the whole TypeScript desiderata of Ok, computer).

And yes, it is nicer to avoid expensive tests if you can help it. It has been my experience, however, that if you can use a slightly-more integrated test - which touches more parts of the system - you are likely to find more regressions and much quicker than if you subscribe to the notion of "testing one function with collaborators all around". It is academically very appealing, and your tests will be quite fast indeed - but they will be much harder to read and understand, and are always one "and_call_original" away from being useless.

As to decoupling from a framework in an ecosystem where, realistically, there is only one framework - and where, realistically, there are no deployment targets except for that framework - I don't believe this to be useful, sorry.

Yes, you can deploy your code into a cloud function (both AWS and GCP do Ruby cloud functions and you can get quite a bit of mileage out of it) but this is not an architecture you are likely to plan for - or need - until quite, quite late into the growth of a codebase. And even then - those runtimes have different constraints, so you may want to build a module which is accessible both from Rails and from such a cloud function.

What I don't like is the conversation of "you must decouple to decouple", which is not a way to advocate for something at all.