I think that this article is good in that it provides a significant amount of detail about many of the complex problems of billing. I don't agree that everything in the article is a big deal, but it certainly calls out a bunch of the things you have to think about, and it's a long, long list. And it's also just scratching the surface - some of the questions lead to many more questions, and significant complexity.
So, if you don't architect your billing platform in a way that properly separates the high level moving parts, you'll eventually end up with a big pile of spaghetti. Which is bad form for something that's so critically important.
That's not to say that you have to implement every single possible feature, or even that separating things is particularly hard. It's possible to build a simple billing system with just a few SQL tables - but they are probably not the exact tables that you are thinking of. But it does means that your billing platform needs to make as few assumptions as possible, and be structured in a way that leaves room for change in the future.
That's because billing is critical to a business' success, and it therefore requires lots of flexibility. One way to find product/market fit is to do your billing in a way that better resonates with your customers. I mean ultimately that's what I think AWS did to colocation. So if you can't keep up with the demands of your sales team or your customers, you're going to be in a bit of trouble.
As engineers, we don't get to set the rules for billing, because that's not how customers work. The billing system needs to support the requirements of the business; not dictate to them how they need to do things.
Anyway I wanted to add a couple more things to TFA, just to illustrate that there is even more to it than they've listed.
Policy management - what do you do when a user spends too much before the invoice is raised? Do you send an email / sms / restrict the service? how do you avoid doing this multiple times in a month? how do you integrate the billing policies with other policy systems such as usage policies? This can get really deep...
Invoice rendering - very few people seem to understand that invoicing is the one time every month that you have the legal right to send unsolicited emails to customers. But in my experience, invoices almost always look like crap. What a waste!
There is heaps more to this: how do you quickly fix billing problems, such as an incorrect plan? how do you backdate changes? what's your pro-rata policy on fixed charges? what do you need to integrate with the finance platform? ... the list goes on.
So please forgive my shameless plug - I'm available for consulting on billing systems any time. I really know what I'm doing. See my profile for contact details.