Linkedin do this for their mobile site (see http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-10-performance-tips-linkedin-mobile part 4), and it's apparently been very beneficial for them from a performance standpoint.
However, I'd suggest you avoid doing the same, for various reasons.
The first is maintainability: C#/ASP.net is, due to it being a server-side framework, client-independent, whereas Javascript is not (even with a framework like jQuery you're not going to get 100% cross-browser compatibility, not future-proofing). I'd say it's also easier to verify the functionality of a statically-typed application than an dynamic one, which is something you absolutely must consider if you're building large-scale sites.
The second is that you're going to find it difficult to find other people who are capable (and willing) to build a pure-javascript application of the kind of complexity needed to run your entire website (compared to the relative ease of finding .NET programmers). This might not be a concern of yours directly, but it certainly is something to think about from a long-term perspective.
The third issue is client-compatibility; if you're building public-facing websites then remember that a reasonable portion of the net still does not have JS enabled (for various reasons), so you'll need to be absolutely sure that you're not going to exclude a large portion of your userbase by switching to a JS-driven website.
As for your bulleted concerns:
I wouldn't worry too much about the security aspect, there's no reason why you could not mix paradigms and do some server-side processing when you require security (you're going o have some view-rendering code in there somewhere that returns HTML, there's no reason you can't have this just fire off an AJAX call instead, when required).
Ease of development isn't really a concern too, in my opinion, there are very good tools available for JS development, don't just box yourself into VisualStudio because you're used to it! (try JetBrains WebStorm, for example).
Performance of JS view engines is absolutely fine in most cases (again, in my experience), I use them heavily on a day-to-day basis. What I would suggest is avoiding the more heavyweight frameworks like knockout.js etc., and head instead for something like Jon Resig's micro template engine. This way you can plug in the supporting code in ways you're confident are fast and reliable.
What I'd do, if I were you, is really examine the reasons behind this switch; It could well be that you're just not leveraging .NET effectively and need to up your game, WebForms isn't a particularly slow framework out-of-the-box, so perhaps some of the 3rd-party libraries you're using are slowing down your rendering.
Try doing a performance profile of the application using a load test and profiling tool, and see where your bottlenecks are before you sink a large amount of time and effort into a more radical solution, you'll probably be surprised at what you find as the culprit for your slowness!
The choice whether to include padding and border into the width or not was arbitrary. The only thing where it mattered was building multi-column layouts. However, you should pay into account the fact that people used tables for layouts at that time anyway. So to them that concern didn't seem important enough and they considered that being able to specify the exact width that the content itself would occupy in CSS seemed a lot more valuable.
For today's developers the situation seem totally different as they use CSS for layouts and they have to deal with CSS boxing model. Thankfully we've got an ability to override boxing rules so in most cases simple rule at the top of your stylesheet works fabulously:
* {
-mox-box-sizing: border-box;
box-sizing: border-box;
}
To quote Jeff Kaufman on the subject:
Given that the spec defined it the other way, though, the signal it would have sent to Microsoft to adopt their misinterpretation would have been bad for the web. Microsoft was already using an embrace, extend, and extinguish approach, where they intentionally made products that acted differently from competitors' in order to lock users into the Microsoft versions. They came very close to succeeding with the web: from approximately 2000 to 2005 IE was so popular that many sites designed just for it. Adopting IE's approach here then might have told Microsoft "you can do whatever you want with IE and we'll adjust the standards to make it legal".
So box model fell the victim of power-struggling between W3C and Microsoft.
Best Answer
Whenever I have encountered heavy HTML generation in javascript, it was almost solely in a stand-alone UI plugin. It makes sense, as it allows to encapsulate the entire plugin in a single .js file (+ a .css to customize styles), thus making it easily reusable, distribuable, and independent from the framework used in the application.
So if you're writing a stand-alone javascript plugin or a generic UI component which you would like to use across different applications, such an approach has its upsides. Otherwise, I think it's both cleaner, easier to write and easier to maintain when you keep html generation away from javascript and on the server side.