> Why not have a simple client side method for this?
Like writing a line of js?
The difference between "a line of JS" and a standardized declarative solution is of course that a meek "line of $turing_complete_language" can not, in the general case, be known and trusted to do what it purports to do, and nothing else; you've basically enabled any kind of computation, and any kind of behavior. With an include tag or attribute that's different; it's behavior is described by standards, and (except for knowing what content we might be pulling in) we can 100% tell the effects from static analysis, that is, without executing the code. With "a line of JS" the only way, in the general case, to know what it does is to run it (an infinite number of times). Also, because it's not standardized, it's much harder to save to disk, to index and to archive it.
A block of in-line JavaScript stops the renderer until it runs because its output cannot be determined before it completes.
A line of JS that has to run through the Javascript interpreter in your browser rather than a simple I/O operation?
If internally this gets optimized to a simple I/O operation (which it should) then why add the JS indirection in the first place?