Shared libraries take time to load. When an application is linked to a shared object, the process loader first checks whether that shared object is already loaded.
If it isn't, the loader must first load the object out of permanent storage (IFS, EFS, or elsewhere). The process of loading the various ELF sections from the file can take time. The dynamic linker must look up the symbol names to get the appropriate addresses.
For a large shared object, it can be significantly quicker to statically link the application with the largest libraries because it links only the parts of the library that are used. By following this practice, you pay for the linker lookup penalties at compile time rather than at runtime. Of course, statically linking an executable can consume more flash memory when multiple applications must make calls to the same library because you'll need to statically link that library across multiple applications. In addition, this practice may introduce version incompatibilities between applications if the shared library changes and you don't rebuild everything that it's linked against. In some systems, the performance benefits often outweigh the drawbacks.
Another advantage of using statically linked libraries for your splash screen application is that it pulls only the necessary parts of the libraries into the splash screen application, which can potentially help reduce the size of your primary IFS. Remember that statically linking your libraries is recommended only for splash screen applications; other applications that run on your system that don't need to show content right after you boot a system should use dynamic libraries. For more information about static and dynamic linking, see the Dynamic Linking chapter in System Architecture.