Even then, the total addressable market was pretty small, but at least it was anyone who wanted to make a cross-platform app.
Now, most people who want to do that use Electron, React Native, or make a browser extension (or, of course, a Web site). The market is smaller: cross-platform makers who are absolutely committed to Qt or for whom it’s a uniquely good fit (like because they’re using C++).
Think of it like a pharma company with a drug that only treats a rare disease. The TAM is tiny. Unless someone discovers that it also treats some other disease, there’s not a lot they can do to expand the customer base. If they want to make more money or want more short-term revenue (usually at the expense of long-term revenue), charging existing customers more may actually be the best option for them.
But now, I think that C++ is more of a drawback than an advantage for the Qt project. C++ today seems a good fit for high-performance, very niche tools such as trading, games, machine learning libraries, and such, but not for "simpler" software such as the UI of an application. Also finding good competent C++ devs seems to be much harder now. I myself feel like having to go "back" to writing C++ is a bummer, having worked with other more modern technologies.
Bindings to other languages have always been a second-class citizen. The Python one is very nice, though, but that's all. I believe it comes, again, as a difficulty introduced by the language itself.
Even with all of that, you generally end up reading the C++ docs, it isn't particularly Pythonic, and there are weird gotchas. I can't really fault them for it because you're bound to get that with bindings to another language and it is much better than other UI toolkits.
If you want to make actual profits, then it is the same license choice but with a company that sells valuable long-term support, development and perhaps proprietary extra features. Examples: RedHat, Canonical, GitLab.
And no, I don't really have an answer either. Successful open source business models are few and far between. Redhat is perhaps the one big example of a (very) successful open source company.
To some extent I think the worry about leeching is something which can be addressed with culture as well as licenses. Plenty of successful BSD/apache licensed projects around, including with largely corporate contributors, because they understand the long-term value from contributing to the common pool rather than forking and trying to sell "proprietary enhanced" versions.
I'd probably go with LGPL and commercial plugins that enhance the functionality. But this depends on the product having some features that could be mainly useful for companies but not really for individuals.
Either go full GPL, or even AGPL, or then use a liberal license like Apache-2, IMHO.
If tomorrow you had some big project such as Qt in your hands, and had 100% freedom to choose how to proceed with it (in matters such as what license to apply, what sustainability model to seek, etc.) what would you do?
I always feel that pure GPL is the best but only idealistic way to go, because working for free is not compatible with paying your bills. Then LGPL, and maybe other licenses such as Apache, are nice but at the end of the day allow that private companies with private pockets benefit from the project without helping it at all (either with work or with cash), which I know is one side of the "freedom" that those open-source licenses bring, but it's one side that I personally don't really like (I'm more of a pragmatist than an idealist). For that reason I feel like dual GPL+Commercial might be the best of both worlds. It would allow basing a company around it, and paying other devs to feed their families, and at the same time users of the GPL variant would themselves be benefiting from and contributing to open-source.