I don't think that anyone suggested that static linking is outright bad! It's just that it can lead to some unfortunate circumstances, that can get libraries like TBB confused. TBB needs a singleton object in order to build one copy of a data structure used for holding a thread pool and managing the tasks it executes. You might be able to do singletons in static libraries but only with a lot of hair an marginal programming to make it bulletproof. It's a lot easier to guarantee the uniqueness of the data structure by putting its manager in a dynamic library that only gets loaded once, rather than if static and loaded by every library whose developers like your library.
Oh, sounds like a survivor of the notorious Microsoft DLL-hell wars. Not all shared objects are bad, just some implementations. :-(
I admit that if you can somehow guarantee that only one copy of TBB is going to be linked in to the entire application, there are some benefits to be had from static linking, and I think it is with this mindset that Alexey even suggested using TBB statically. All too often though, we live ina world of multiple libraries, each used in myriad combinations with various applications. To keep life sane, TBB so far has held to the convention of only linking dynamically. Source code is available for anyone who wants to blunder, uh,... venture down that path.
No, not different applications but applications that use multiple libraries. We have a variety of libraries at Intel that are starting to use or already using TBB as a basic threading resource or a basic memory allocation resource, or both. Applications may want to use multiple of these libraries in order to make use of their functions, and therein lies the rub. If each of those libraries has a static copy of TBB, the singleton requirement will not be met and within the application process may be divisions in memory pools as well as multiple thread pools.