Software vendors have a variety of attitudes to open source libraries. Some will use open source libraries without looking at the terms of the open source licence, and some will not use any for fear that the open source library will contaminate their own intellectual property. Rarely a software company will evaluate software licences for individual libraries to determine whether they can, and are prepared to, meet the requirements for using the library.
Recently Cisco was accused of breaching the GNU General Public Licence in its Linksys range of products. If a giant like Cisco can get it wrong, smaller software businesses might think compliance with open source licensing is an unbearable burden.
The more paranoid approach to open source may be safer, but may also cost more if the business has to reimplement all the functionality of the library. Significantly, an open source licence is very unlikely to compromise the rights you have to your own code. Breaching an open source licence may have consequences (including, where the code has been mixed with your own, preventing you from redistributing it), but even if your code is a derivative work, the parts you create yourself will not normally be "virally" licensed under the open source licence unless you decide to licence them that way. The worst that can normally happen is that you have to remove the code taken from open source libraries and anything that is derived from that code.
The extent to which the library licensing will affect commercial code will vary depending on what parts of the library are incorporated into the combined work distributed to clients. When you use static linking your distributed software will include substantial protected parts of the library. With dynamic linking the answer may not be as straight-forward. In the case of a "C" program, the distributed software might not include any of the protected parts of the library, but in some cases, particularly with large macros or header files that include significant amounts of code, there may still be substantial portions of protected library code embedded in your distributed software. In the case of C++ libraries there is a greater chance of the distributed software including substantial portions of the library, especially if your software uses C++ templates. In the case of Java libraries it is very unlikely that any of the protected content of the library becomes embedded in your software.
Even if your own distributed code does not have embedded library code, you will often need to distribute the library code with your software in order to provide customers with a usable installation package. Doing so may require you to do things that you are either unwilling to do, or cannot be confident will be done consistently or reliably. Ensuring compliance may be a simple matter provided you establish processes that increase consistency and reliability.
If you do want to use an open source library in your commercial product you should get advice on the ramifications of doing so separately for each licence - and each product - before undertaking any development. Not only is there a risk of being sued (and publicly shamed) if you get it wrong, but without early advice you may waste significant time, money and resources developing something that you cannot lawfully sell. However if you get the licensing right, using open source libraries can reduce costs and development time while increasing software quality.