Every single binary every emitted by LLVM has been Bitcode during the compilation process. The only new element here is that Apple's asking for this intermediate product in order to be on the App Store.

Yep, and what I'm saying is that Bitcode doesn't help portability; only in producing device-optimized binaries for variants of the same ISA. The end goal here is reducing app size, not making it easier to port things to a new ISA. A new ISA wouldn't be impossible -- Apple is one of the few companies to successfully navigate this transition -- but IMO Apple would be better served on the Mac side by lower-power x86 parts (which are finally available) than higher-performing ARM CPUs.

In my industry, app data size swamps app executable size by a factor of about 2000.. So all this app thinning stuff seems useless (to me).

That's not universally true (as you seem to indicate already). For example, I included Google's WebRTC libraries in an iOS app and it bloated the binary by several hundred megabytes per architecture. Thinning that would help a lot.

Resources are a big part of it too, of course. A typical iOS app these days has three copies of every image, for 1x, 2x, and 3x resolutions. Dropping that down to one copy on the device is helpful. Of course this doesn't require any of this bitcode stuff, although neither does thinning the executable.

FFmpeg on Android also tends to make apps ridiculously huge when needed due to the need to support multiple architectures. Worse if you want something like x264 as well.

Well-optimized, lean apps often use cache and registers more efficiently. This brings performance boosts. That can save real $$$ on hardware or just let you do more with it.