Let's not forget that they are a hardware vendor.
I don't think it's some grand conspiracy theory, but the interests of the vendor and of the user are not precisely aligned when it comes to efficient usage of storage. (The lack of stripping applications of their alternate language content on install/download also comes to mind.)
(For example, removing @2x images for a plus device that uses @3x images, or vice-versa).
Afaik bitcode is so that Apple can rebuild binaries for different target architectures (e.g. new models of phone, watch, et c) without source developer interaction. It should come in major handy in the OSX app store when ARM64 Macbooks ship in a year or two. A full app store of working apps on hardware launch day will make the bitcode requirement worth it when it's the smoothest architecture transition they've ever done (out of 680x0->ppc and ppc->x86).
Bitcode can used to recompile for minor ARM updates, compiler bugs, new optimizations etc without having to get developers to submit new binaries.
Kind of.
On IBM i, C compiles to TIMI bytecode just like everything else. For producing actual native code directly from the compiler you need the Metal C compiler, or the POSIX compatibility environment (PASE).
The TenDRA C and C++ compilers also used bytecode (TenDRA Distribution Format).
As for alternate language content, honestly that stuff doesn't take up very much space, and stripping it would break the code signature. The only way Apple could strip that is if they perform the equivalent of App Thinning based on a list of languages you specify when downloading the binary from the App Store (and even that wouldn't apply to downloading non-MAS apps).
Yeah. It's not like Apple had to settle lawsuits about batteries that seemed to be designed to break after a while. Oh, wait...