Though even the solution to 1 doesn't solve "ACLs", which distribution does. If you want to ensure your module is only called by an approved list of upstream modules, public / private isn't granular enough. (You can solve it with attributes or some build tools, but it's ad-hoc and complex, doesn't integrate with the editor, etc. I've always thought something more granular and configurable should've been built into Java/OOP theory from the start).

That said, 2 is really the big problem. As things really scale, this tends to cause problems on every deployment and slow the whole company down, cause important new features to get blocked by minor unrelated changes, a lot of extra feature flag maintenance, etc. 90% of the time, that should be the gating factor by which you decide went to split a service into multiple physical components.

As the author said, an additional reason for distribution is sometimes it's prudent to distribute because of physical scale reasons (conflicts between subservice A needing high throughput, B needing low latency, C needing high availability, and D needing high IOPS that blows your budget to have VMs that satisfy every characteristic, or impossible in memory-managed languages), but usually I see this being done way too early, based more on ideals than numbers.