First let me say that this is a great article. It shows a wonderful use of SQLCLR for an area that T-SQL is just not well suited to. In fact, I had looked into adding a JSON library to my SQL# project just over a year ago but it required UNSAFE permissions so I moved on to other features. The only thing missing from the article is a description of how the metrics were gathered (unless somehow it's there and I missed it).
Now, onto this:
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.
False and False. Performance is just as easy to screw up in regular T-SQL, especially given how prone people are to using row-by-row approaches and how likely people are to not understand the concept of SARGability. Security in CLR Procs and Functions use the same security context as regular T-SQL Procs and Functions.
Whether or not the functionality should exist outside of the DB is an entirely different discussion. The fact is that a lot of people have a lot of various needs so to have this ability will definitely help some/many people. In fact, SQL Server is kinda late to the game in terms of allowing people to use other languages to extend functionality. DB2 has had the ability for over 10 years and PostgreSQL allows for maybe 5 other languages at least.
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?
DBA's not being familiar with .NET code is a moot point. Most system admins aren't familiar with much of the 3rd party software, such as RDBMS's that are installed on their networks but they still support them. And we all use software that we would never be able to write. And DBA's are not necessarily good programmers anyway and can do quite a bit of damage with the built-in T-SQL that they feel so comfortable with.
3. There are many shops which use SQL Server as their standard RDBMS, but do not use .Net for application development.
Again, an entirely moot point. If the CLR Assembly can be installed and works as advertised, then that has no negative impact to a JAVA shop. It is only better and easier for a shop that is .NET savvy. Besides, it is common for shops to have a mix of platforms and languages.
-- this is from another post by Craig, but on the same topic:
There will be two platforms for some time, but mobile computing is where the growth is, and MS definitely knows that.
PS. 'write once, run everywhere' is mostly a marketing term. Different physical devices and even OS's all have their nuances.