Giving each an individual key is trivial, and even desirable since content is rehused by other books all of the time. I'm not convinced this would be that costly in a way that could be quantified and given a price tag.
Well, right there we see part of the issue.
Assume that each bit of game-rule content (like a race, a class, a subclass, a monster, a spell, etc) is identified with some key for use by the software. I don't know that is how the architecture works, but let us assume it.
Let us also assume you are correct, we expect them to reshuffle bits of content and have it appear in many different products.
That means that when selling a product, we need a separate product key, that will map to a list of software content keys on the back end. The business needs to be able to create new product keys, and mix and match their product keys with the back-end content.
This implies a whole process of management of the products for sale, and what software bits they are associated with. In some places I've worked, that process was manual, and some engineer had to go and manually edit database entries when a new product was defined. Or, maybe they have a software tool to do it for them.
So, either there's some poor engineer who gets called on to create product key listings, or there's a system that will need maintenance and updating when D&DB changes.
Either way, the more product keys you intend to manage, the more of a burden that becomes. Reducing the number of product keys by eliminating al la carte purchases would be one way to cap that burden.