I agree there are certainly other models that would make sense, given that this is probably a library that's going to be incorporated as part of a larger project rather than a standalone piece of software for in-house use.
It seems reasonable to have a predictable price up-front, particularly one that can be transferred to a client as part of an overall project budget if necessary.
It also seems reasonable to have a more transparent level of scalability. Something like per-domain pricing might make a lot of sense as an approximation of buying it once for each project where it'll be used.
I suspect a commercial project like this is mostly going to be used by larger organisations who aren't going to sneeze at real money, because there are too many good-enough alternatives for the little guys. That being the case, if you want to allow for increasing value as a project grows, you could do something like per-(public-facing)-server instead of per-developer and just make as many in-house machines as you want free.
That might be awkward with cloud-based projects that activate and deactivate instances on the fly, so maybe just band it "$x for up to n public servers/instances at once", "$y for up to m public servers/instances at once", "for more servers/instances contact us for special rates".
Licensing is always a mess, unfortunately. I think the best you can ever do is probably to present something that is clear in what is covered, realistic in what it costs, and reasonably consistent/predictable.