My experience is that the scope is never kept narrow, which is exactly the same that the author is describing.

Well, you can - you can have a policy that forces payments from a select group. Some users will complain when "No, you cant pay with 2 chickens every 3rd full moon", but that is too bad.

Of course you then have to be willing to turn down money/customers. As someone who has worked for quite large companies, we've ended up not buying from certain companies because they couldn't invoice us like we wanted to be invoiced.

And miss out on all the fun with buyer-created invoices?

I built a billing system for a web hosting company in PHP, almost 20 years ago. This was for a few hundred users. There were a couple of edge cases, but nothing incredibly challenging.

Was it a basic subscription model or have you faced challenges with taxes, usage-based components, entitlements, grand fathering?

Basic subscription and it was 20 years ago. There was some grandfathering but that was pretty simple to solve with a status column on a plan table, etc.

The use case is tiny at the beginning but the complexity increases over time to be honest. The scope is never as narrow as you think at the beginning of the project. Libraries are great, they can help you implement faster, but if the company grows, you will need an entire team to build and maintain it