However, that's not the case right now. Maybe in the future Javascript's string parsing will become dramatically faster, but in my benchmarks elsewhere on this thread, it's clear that for large files less.js is pretty slow relative to HTTP.
As for serving it up as JSON: no one wants to write stylesheets in JSON. The reason Less became popular as an alternative to Sass was that it had a CSS-like syntax.
You don't have to. You can use a compiler to generate JSON to feed to the system, retaining the flexibility of having the compiler running but skipping the parsing step. Why not compile straight to CSS? Well, why not? For simple sites that may be just fine. For more complicated sites it might be desirable to screw with the CSS before compiling.
My real meta-point here is that compiling isn't that scary. The idea of load you may get from g++ or GHC is not generally applicable. And as JS gets closer and closer to C-speeds it'll matter even less. (Not saying it will reach them, but you don't have to.) And there are already quite a few compilers in the mix; every web language has one (JS, CSS, HTML, SVG) and adding another is not like an enormous scary step. I suppose this is another consequence of the continuing deplorable move away from having compilers be a required class for a degree; truly it is one of the most powerful techniques of computer science that is relatively difficult to fully encounter outside of a formal education. (Like everything else in programming, it isn't impossible, but as it is very easy to walk away with a degree without ever having encountered one, so much moreso it is easy to not encounter one in informal education too.)
I'm certainly not afraid of compilers. I write Sass, so I'm pretty intimately familiar with what's going on. My point was not that compilers are inherently scary and/or slow (although I stand by my original point that if it's compiling to CSS it will always be at least somewhat slower). I was just making the claim that the current speed of less.js is too slow for practical production use.
However, I would submit that string bashing also ought to be amenable to JIT optimization. What will kill you in the browsers is interacting with the DOM/browser itself, and that's not going to go away as that code is increasingly already as optimized as it's going to get. However, CSS already has that problem, so if you can dynamically snap some CSS together on the client side and then feed it to the usual CSS processes, it doesn't have to be a large loss.
I also expect the browers to continue to work towards support more of this stuff being done dynamically; if you can better hook into the page generation process, you can help the browser avoid extra stupid work, like starting to layout the page with the entirely wrong CSS. We're still a ways from this entire process being optimized; I feel we've finally left the stupid ages in the browser world, but we're still working.
Even better: Or does your processor natively execute HTML text?
Well, it's way too late for that. You need to send that statement back to mid-1990s.
Or does your processor natively execute Javascript text?
That dogmatic declaration is nonsense. Compilers are just code. Certain programming language compilers are very slow due to the immense complexity of their task but there's nothing intrinsically slow about compilers/interpreters next to any number of other normal tasks. I've even sped code up by replacing large swathes of ad-hoc hard-coded crap code with a nice small interpreter that was small enough to be feasibly optimized, rather than the mass of code that was previously there that everybody was afraid to touch.
The really slow part would be the parsing, really, and if Less.js doesn't already have a "straight from JSON" mode, it would be easy enough to add one, then you could actually use the "native" Javascript parser and compiler.