What do you mean by connect "directly" to the server?
I mentioned before that the context connection could connect "directly" to the server and bypass the network protocol and transport layers. The context connection follows a shorter code path and involves fewer components. Because of that, you can expect the context connection to get to the server and back faster than a regular connection. Query execution time will be the same, of course, because that work needs to be done regardless of how the SQL statement reaches the server.

Restrictions for the context connection
Here are the restrictions that apply to the context connection that you'll need to take into account when using it in your application:

• You can have only one context connection opened at a given time for a given connection. Of course, if you have multiple statements running concurrently in separate connections, each one of them can get their own context connection. The restriction doesn't affect concurrent requests from different connections; it only affects a given request on a given connection.
• MARS (Multiple Active Result Sets) is not supported in the context connection.
• The SqlBulkCopy class will not operate on a context connection.
• We do not support update batching in the context connection.
• SqlNotificationRequest cannot be used with commands that will execute against the context connection.
• We don't support canceling commands that are running against the context connection. SqlCommand.Cancel() will silently ignore the request.
• No other connection string keywords can be used when you use context connection=true.

Some of these restrictions are by design and are the result of the semantics of the context connection. Others are actually implementation decisions that we made for this release and we may decide to relax those restrictions in a future release based on customer feedback.

Restrictions on regular connections
inside SQLCLR
For those cases where you decide to use regular connections instead of the context connection, there are a few limitations to keep in mind.

Pretty much all the functionality of ADO.NET is available inside SQLCLR; however, there are a few specific features that either do not apply, or we decided not to support, in this release. Specifically, asynchronous command execution and the SqlDependecy object and related infrastructure are not supported.