If this is correct then the lgpl would be ideal?
Also, it depends how much value-add they see their modifications having. For small tweaks and bug fixes they'll contribute it. If they invest a lot of money into something, they'll be loath to hand that value over to their competitors. There is some tipping point where the competitive value (or more realistically the jealous urge not to share) of their efforts exceeds the utility of easy tracking with upstream changes.
Ideal for whom?
It's still not ideal for downstream proprietary developers. The requirement to provide some means to relink the project is extra headache that can be avoided by using permissive dependencies, reinforcing the point of the article.
Also, in theory, I can imagine a situation where a proprierary developer strongly needs to make a change, and for some reason is strongly against open-sourcing it, and is strongly law-abiding. And thus, a proprietary rewrite is born. Sometimes, instead of a complete rewrite, that's going to be a fork of a permissive project, boosting its usage and reinforcing the point of the article.
For library authors, LGPL/MPL is often a good tradeoff, indeed. You still get all the modifications back, while also having more users then you would have with GPL. Although, as seen in this thread, enabling proprieraty dependents is actually a downside for some authors, due to their beliefs.
To me, it looks like LGPL/MPL become irrelevant in the "longer" run too.
---
I agree with you regarding the "tipping point". There's nothing we can do about this. In a similar vein, when considering a massive investment into a GPL project, they are going to conclude that they are better off invesing a similar amount into a proprietary rewrite and keeping the added value to themselves.