What are the risks of not relying on the certificate chain for SSL certificate validation and instead manually importing the certificate as trusted?
One is related to the fact the chain of validation typically includes a CRL and/or OCSP service to query for invalidated, but otherwise legitimate, certs.
In other words, a cert may be technically valid, but have been invalidated because its private key was compromised - CRL and OCSP are standardised ways of dealing with revocation, which is not generally the case of manual certificate management.
I would also tend to think this is a waste of resources: why expend additional effort on meeting a need that has a better, and more to the point, standardised, solution?
Especially at any scale, surely this is also inefficient: versus the one root (or e.g. 5 root + intermediate CAs) you might want to trust, you would need to distribute X end-entity certificates, and additionally, would be bound to the issuing CA's lifecycle for certs in terms of needing to re-distribute new certificates.
What additional risks, if any, are there for not keeping the list of trusted root CAs updated?
As mentioned, revocation is one area that springs to mind: absent an effective revocation mechanism, a trusted CA merely indicates that something was, at some point, trusted. It has no clear significance for whether this same 'something' is now trusted.
Without maintaining your trusted roots, I would tend to think you are rendering much of the purpose of x509 moot: trust is a transitive property, and any assumptions to the contrary have tended to be exploited for malicious purposes.