Why do some applications/VIP's need a root certificate to be installed in the F5?

If I may add, the "chain of trust" $amir is referring to is a product of PKI (public key infrastructure). A root certificate is almost always a self-signed certificate - it's issued to itself from itself. We'll call that the "anchor" of a particular PKI. Every party that wants to communicate with others in that party must explicitly trust that root CA. For client browsers that means storing the CA certificate in the browser's trust store or in some other keystore location. For a server it usually means storing it in a file, folder or other keystore location. Now normally root CAs aren't used to create end entity certificates (users, servers, etc.) because the value of the root CA is too valuable to risk its compromise. So a root CA is used to issue subordinate CAs that will do all of the day-to-day work. And now you have a chain:

Root CA
    -> Subordinate CA
        -> End entity certificate

That chain can actually get many levels deep as subordinate CAs can issue sub-subordinate CAs, CAs can cross-certify with other PKIs, etc. In any case, when a client receives a server certificate from a server as part of an SSL handshake, it has to validate that certificate. The first validation is simply a correctness check. Is the certificate expired? Is the subject or subject alt name in the cert the same value as what I asked for? Does it support the crypto that I support? Can I support the x.509 attributes it presents? etc. If that's good, then the client must then validate trust. It does that by attempting to create a chain from the certificate back to its explicitly trusted root CA. So if the chain is 3-levels deep as in the example above, the client must have access to all 3 certificates. Each certificate has a cryptographic relationship with its issuer and subordinate. If the client doesn't have the subordinate CA, the server can give it to him in the SSL handshake. But it CANNOT give it the root CA. If the client can build this trust, and everything else looks good, then the SSL handshake continues without errors.

At this point I've only talked about one-way authenticated PKI, where the server presents its certificate to the client only. And in that case the server has nothing to validate and your BIG-IP VIP should not need to have any CA certificates configured in its SSL profile. You could, however, add the subordinate CAs to the chain option in the client SSL profile so that the server sends these subordinates to clients that may not have them. But what happens when you want to do mutual authentication? Where the server asks the client for a certificate. Well, the same process happens in both places. The server sends its certificate to the client which the client validates, the server asks the client for a certificate, the client sends a certificate, and then the server (BIG-IP VIP) must validate the client's certificate in the exact same way the client did it. The client may or may not have the subordinates, and may or may not send them even if it has them, so the server (BIG-IP VIP) must explicitly have all of the CAs in the chain, defined in the Trusted Certificate Authorities option of the client SSL profile, in order to validate its trust in the client's certificate.

So in short, a CA (or bundle of CAs) must be specified in the client SSL profile if the server (BIG-IP VIP) is requesting client certificates.