> The bundle is also customized to the device, meaning an .aab file ripped off a device
.aab-files don't ever make it to devices, they're just for transporting the app from the developer's system to Google for further processing and then pushed back out to devices as regular .apk files (albeit indeed split up across multiple files).
> won't necessarily be loadable on another device since it could have different configurations/hardware that happen to limit it.
For the purposes of independently archiving apps it is a bit annoying, sure, but the only hard dependency is having the correct CPU architecture for apps containing native code, and in practice almost everything runs on ARM, with only the 32- to 64-bits-transition providing some potential roadblocks. (Or I suppose if you wanted to run an app taken from a phone on an x86-based emulator.) Otherwise, you'll "only" be missing additional languages and display densities for graphics resources, but the system already needs to be able to fall back to whatever language and graphics resources are available in case the developer didn't even include them in the first place.
Plus for a while Google itself had a feature in the Play Store that allowed sharing free apps to nearby devices via Wifi, including apps with split APKs. (Though I never tried it in practice and it seems that last year they removed that feature again, so yeah…)