I'm inclined not to use this approach, for these reasons:

1. As the author indicated, using the CLR within SQL Server opens up a number of potential performance and security problems. The author's code is quite admirable, but, I feel, ought to be executed outside the SQL Server environment.

2. DBAs generally are not facile at writing .Net code. Such would typically be a task for .Net developers, not DBAs. The author mentioned reviewing a T-SQL-based approach to JSON serialisation/deserialisation, but rejected it because of its length/complexity. Still, I wonder if revisiting a T-SQL solution might be worthwhile, in part for the reason of making it more accessible to DBAs?

3. There are many shops which use SQL Server as their standard RDBMS, but do not use .Net for application development. Also, the future of .Net is uncertain, with rumours abounding Microsoft is considering its replacement by HTML5/JavaScript. Again, why not reconsider a T-SQL-based solution for JSON serialisation/deserialisation, as SQL itself is in no danger of being replaced by another language/framework, and is more universally understood by DBAs and developers than is .Net?