Well, when you produce the compiler that produces 100% hardware optimized, portable code you let me know, and we will both be Billionaires, okay?
Nobody, EVER, has done it yet. Once you look at what a compiler... a General Purpose compiler.. really has to do, provide both flexibility and a stable framework.. yet simple enough to work in abstracts.. it can NEVER really be optimal. It can get dang close, might even LUCK upon it.. but compiled code IS macros written by someone else, strung together... every single inefficiency in their code becomes your code. Unless you trust that the compiler authors absolutely got every code optimization right in THEIR code, you can't trust that your compiles to the most efficient, even if you assume the "perfect" compiler and optimizer. You sacrifice efficiency for the ease of use... and even then, the programmers of the compiler may choose a less efficient method of doing a particular task simply because they were taught a particular theorem, or even just because doing it "n" degrees better will take "n^35" effort.... If code optimization was easy, compilers wouldn't exist and Interpreters would be just as efficient, minus reading the code's bytestream from memory. In terms of actual storage space for the application code, tokenized statements (10 Print "Hello World") are frequently smaller than their compiled code running on the CPU. It's again just a matter of choosing the right tool for the job. Screwdrivers are really useful, but there are things you can't do with a screwdriver. Well, maybe you could threaten to poke someone in the eye with a screwdriver to force them to give you the actual tool you need, and get it done that way, but you get the idea.
Shell script is better than a poke in the eye with a screwdriver. Barely.
Anyone who laughs at Visual Basic has never done any real world coding... show me a professional that doesn't consider PERL an indispensible tool. Very few thing are as inefficient as Shell Scripting, but try and live without it. These are all Interpreted languages, at BEST, VB compiles into P-code. "HAL" - the Hardware Abstraction Layer - of any OS is pretty much where application programming begins.. so by definition, any software is already "bloatware" by nature of an OS. An interpreted programming language is horrid from CPU efficiency standpoint- but when you need it to simply WORK, "Bloatware" isn't bloat at all, if it provides the only REASONABLE way to perform a task. MAYBE I could walk to California, but I'd be foolish not to take a plane instead, despite a 747's poor fuel economy.
Theory would have you chase down every clock cycle. Practice makes you realize the clock cycles aren't important if you can't make it do what you need with a reasonable amount of effort. I'll trade a little efficiency for a working product, rather than have the most efficient design ever, that never gets built..