2. It is long and complex license, not yet tested in court. Sometimes what constitutes a "derivative work" is not that clear.
3. Section 6 says all these can be changed anytime, potentially making it more restrictive (see GPL v3).
So from the business viewpoint it is better to find an alternative now than to potentially lose all the investment later.
Static linking is fairly uncommon; it's more common to distribute the versions of DLLs you require on Windows, or use a package dependency on specific versions (or provide your own copies) of the system-provided libraries on Linux.
3. Section 6 says all these can be changed anytime, potentially making it more restrictive (see GPL v3).
Section 6 of LGPL3 does not say that; it says that you have the option of choosing a later version. Any code released under "GPLv2 or later" can still be used under GPL2.
These kinds of licenses are put in place so people can't create proprietary extensions/patches and fracture a community. Now, I'm not saying this is better than MIT, but at least deters people from that.
1. will only matter if you are distributing binaries to clients/customers, which generally isn't the case with a SaaS product.
GitHub started out as SaaS and now offers Enterprise product https://enterprise.github.com/
On the other hand I try to avoid GPL/LGPL for components.
Here is a scenario:
1. Invest in developing your app based on CppCMS
2. It takes off, great - buy commercial license.
3. The next version of LGPL gets more restrictive, you're stuck with commercial license.
4. Artyom gets hired by Google/Apple, no time for CppCMS anymore; only the LGPL fork gets fixes from now on.
5. Throw away your investment (time and money), start learning something else - how cool is that?
The LGPL only requires that binary distributions of the derivative work have source reasonably available and that the library can be switched for another version by an end-user.