But why do you care that much about how the user is running your code?

Maybe my laptop is running Alpine and I patches some libraries to support musl and now some methods are NOP. As the developer, why does it matter to you?

You would want me to have some chroot or container installation for me to install a glibc based system so that you can have a consistent behavior on every computer that happens to run your code? Even the ones you do not own?

Developers would generally like their application to work. Especially in the hands of non-technical users. If you're going to take things apart and take responsibility for when something breaks, go ham, but when devs find that their software is broken for many users because a widely-used distribution packaged it wrong, then it's kind of a problem because a) users aren't necessarily going to understand where the problem is, and b) regardless, it's still broken, and if you want to make something that works and have empathy for your users, it's kind of an unpleasant situation even if you're not getting the blame.

It matters because as a developer I'll get support requests from users who claim that my software has issues, even when the root cause is unrelated to my code. If I explicitly document that I support a single way of deploying the software, and that way is a self-contained artifact with all the required runtime dependencies, which was previously thoroughly tested in my CI pipeline, then I can expect far less support requests from users.

Again, this matters a lot to smaller projects and teams. Larger projects have the resources to offer extended support for various environments and deployment procedures, but smaller ones don't have this luxury. A flood of support requests can lead to exhaustion, demotivation, and burnout, especially in open source projects and those without a profitable business model. Charging for support wouldn't fix this if the team simply doesn't have the bandwidth to address each request.