Every module added to a WHMCS installation registers its own hooks, its own database queries, and often its own cron jobs — and none of those third-party developers are optimising against each other's code. Install enough of them, which most hosting businesses eventually do to reach feature parity with a modern billing platform, and the client portal that's supposed to feel instant starts measurably dragging: slower invoice loads, slower login, slower everything, because every page render is now touching a dozen loosely-related plugins instead of one coherent core.
This isn't a theoretical performance concern — it's the most common technical complaint I hear from hosts running heavily-modded WHMCS installations: page load times that crept up module by module until nobody could point to a single cause, because there wasn't one. The slowdown is distributed across every add-on, which is exactly what makes it so hard to diagnose and fix within the existing architecture.
A billing system with automation, payment rails, and provisioning built into the core — rather than assembled from separately-maintained modules — doesn't have this failure mode, because there's no plugin layer generating uncoordinated queries against your database. That's not just a performance win; it's fewer things that can each independently break, and one place to look when something does.