Not at all. My response was admittedly a bit Spartan.
Office objects are designed to be used on a client system, not a server, and they are notorious for having memory problems and can make any system unstable. This is not to mention that using them would force you to mark your SQLCLR objects UNSAFE, which I never condone. The SQLCLR is most conservatively used to extend the Transact-SQL language (i.e. all objects can be marked SAFE) and do not need to reach anything outside the database engine itself (i.e. no need to access the file system, the internet, network resources, DLLs or assemblies external to what the SQLCLR provides by default etc.). SQLCLR is not an open offer to implement full-scale .NET functionality that would access resources outside the database engine. If you are developing an object and find it needs to be marked EXTERNAL_ACCESS or UNSAFE it is a sign you should go back to the drawing board and try to find a different way. I may hold an overly conservative view on the topic according to some but I prefer to keep servers hosting applications (.NET, Java, etc.) and servers that host SQL Server databases on distinct and separate physical entities (servers) that do not share any resources. Resist the urge to turn SQL Server into an application server; that is what Windows and stand-alone .NET applications (of which SSIS is a type) were designed for.
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato