Before I get into the reasons why I find this architecture particularly interesting, lets do a quick flyby review of the architecture itself. Most web applications use some kind of a server-side templating engine to generate dynamic HTML based on backend data. In the Java world this is typically done using JSPs, but an equivalent exists in all languages – ASP.net for C#, ERB for Ruby/Rails, Django for Python etc. In the world of Force.com, Visualforce fulfills this role and you typically pick from the standard Visualforce component library to generate dynamic web pages based on Force.com data. Client-side templates on the other hand get the ‘raw’ data from the server (typically via REST/JSON) and assemble/generate the dynamic HTML in the browser. With client-side templates, the UI code and logic is completely independent of the server-side technology stack and you get a very loosely-coupled, reusable UI architecture. You could of course achieve something similar without a client-side template library (for e.g. making the REST callouts in JS and then doing DOM manipulation using a library like JQuery), but client-side templates are a more reusable and offer better separation of concerns. The ‘before and after’ diagrams included in the LinkedIn article show the differences between server-side vs client-side templating perfectly.
To be clear, I’m not advocating the use of this UI architecture over the native templating and data-binding offered by Visualforce (and it’s equivalent in other languages). Server-side templating should continue to be the default choice for most web applications as it offers many benefits like performance, security etc. In certain cases however (polyglot and mobile apps for e.g.), it is worth considering an alternative UI architecture like the one LinkedIn has adopted.