Rails dev here with 10 years on Rails and ~ 20 years in total.
All of these bar scaling can be done in the monolith. I've worked in uService and monolithic apps or various quality. I've worked on monoliths that were built with services internally using namespaces and gems etc. I've worked in apps that had 8-10 services and a mono integrator. Once a monolith is broken up into 'services' at the logical level then many of the reasons given for going distributed become almost moot against the obvious pros of keeping code in one place.
In the uService setup you might save on testing components but then you tend to lose it in integration testing and just the undeniable complexity that comes with the uService architecture.
I would say this article is about 5% of the thought you'll want to do before transitioning. Every single issue becomes harder with a distributed architecture. I mean just debugging why a transaction didn't work can be difficult and you start wanting to add idempotency keys and transaction IDs to your messages so you can bundle things up in analysis later as well as prevent doubling up of actions.
I would say in your 'reasons to split' section the only one I would ever include would be if you have a feature that you need to scale independently of the rest. To me scaling (i.e. performance) is the only reason that would necessitate splitting a monolith. As usual performance is highly custom in solution hence why generic uService guidance is typically useless.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.