This is true.
However, even with that enforcement, those guarantees don't prevent you from implementing a bad architecture. And unless you're a domain expert on the project and a general SoA expert, you will most likely get it wrong on the first attempt.
You must know what your boundaries are before separating functionality into services. Practicing SoA may guarantee that you do SoA correctly, but it introduces significant overhead if you get those initial boundaries wrong.
It's more like how Haskell will guarantee you write pure functions, but won't guarantee good functional design. SoA guarantees your services look like services, but won't guarantee good multi-service architecture. The difference is that fixing a handful of incorrect functions and fixing a handful of incorrect services is the orders of magnitude in difficulty. So yeah, still start with the call stack. At least until the boundaries become stable and clear. Dealing with SoA impurities after you've identified the boundaries is way easier than coordinating multi-service refactoring or working within a broken SoA.