The current model in which a developer generates an assembly and then passes it to a DBA and says "trust me" is failing to allow for the typical dynamics involved. To the DBA, this assembly is like a black box.
Also, the current model ties databases directly to versions of the .NET Framework. While there is currently only a single supported version of this now, this won't remain the case and will lead to a versioning mess in the future. DBA's won't want to hear about things like publisher policies, etc. or whatever will be required to deal with it.
Further, the current model requires a DBA to be comfortable with Visual Studio, even when implementing what would otherwise be simple managed code functions. This is harming SQL CLR adoption.
If the managed code source was processed when scripting a database instead of the assembly binaries, much of these issues would be avoided.