As others have noted, a big part of the role of the splash screen is to make sure that the user sees the word "securely" and gets the impression that "something is done about security". The best security systems are invisible (when you don't see anything, and business proceeds unimpeded, then the security systems are optimal), but the general public does not know that; the public expects security to happen spectacularly. Deep in their mind, users would not be surprised if using a "secure Web site" made all the room lights turn red, like in a submarine.
For that matter, the psychological effect may be directed at the bank manager, too: he paid for a "secure Web site" so he wants to see some security happening. That species of no-nonsense businessmen with limited grasp of technology is still prevalent in the upper layers of management.
There are a few "rational" reasons that may explain a delay. They are not probable; most sites with a delay still do that only for the security theatre. But they might apply in a few cases:
The delay may be due to the background launching of some applet (Java, Silverlight, ActiveX...) which has a slow initialization process, and tries to do some "extra security" in some way (such a system will be needed if client-side signatures are used).
Verifying a user password may entail some non-negligible computing effort if proper password hashing is used. This can imply some delay, especially if "server relief" is used: the bulk of the hashing may be done client-side, so that the server may handle hundreds of clients effortlessly. In that case, the hashing proceeds at client speed (Javascript...), so this can take a few seconds.
The server may want to prevent massive dictionary attacks by imposing a delay of a few seconds between any two requests from the same IP and/or for the same account. This delay can be made intrinsic if a proof-of-work system is used (but, there again, Javascript won't help).
The delay may be needed for the server to open tunnels to a bunch of old legacy systems where the banking data actually is. Banking software must strictly adhere to a huge number of rules, encompassing both the actual code behaviour (in particular rounding issues) and development methodology (line-by-line independent audit and so on); the consequence is that such software is not created often, and old systems tend to linger a lot. Last I heard, many banks are still using OS/2. Convincing all these systems to power up and find some user's data can take a few seconds... If the system is going to be slow, what better excuse than to claim that it is "for security" ?