It's not a reasonable approach because these binary blobs they're installing are guaranteed to be non-functional unless the target OS somehow happens to be the exact distribution and version the binary blob developers are testing for.
(You could theoretically make a truly portable and hermetic binary blob with something like WASM, but I guarantee you this black magic is not accessible to IDE developers.)
They address this in the article - they're statically linking with musl, which should address most distros, and their phrasing indicates that they're testing multiple distros too.
> Unlike our normal Linux builds, the remote server can be compiled with musl, which requires no dynamic linking. This lets it work on older distros (where before we ran into compatibility problems with glibc) and on modern share-nothing distros like Nix that don't have a global set of libraries to dynamically link.
> these binary blobs they're installing are guaranteed to be non-functional unless the target OS somehow happens to be the exact distribution and version the binary blob developers are testing for.
Whoever makes publicly available binary blobs are necessarily aware of all those issues and try to engineer them to be resilient enough for most environments. That's why they typically work well even though they generally have little information about the system besides from most basic ones (ISA, OS/kernel and ABI to be precise). This is significantly more difficult in Linux due to its higher variability, but not even close to impossible.
(You could theoretically make a truly portable and hermetic binary blob with something like WASM, but I guarantee you this black magic is not accessible to IDE developers.)