Yep, pretty much. I mean I guess it makes sense for containers because the only thing running there is that app anyway, although most good containers set up their own user. For example, the node container has a node user with ID 1000 which is more typical for Linux systems. Docker in particular is often used by Windows/Mac users that aren't necessarily familiar with the ins and outs of Linux and just want it to work, which in a container, is usually fine. With rootless containers, even root in the container is basically useless anyway because it truly runs as a fake ID on the host.

But yes, even in the Linux circles, there can be dubious advice or just bad habits. The thing with doing things right is it takes a lot of time, and sometimes, you really just want to make it work. Just look at how many people just sudo whatever whenever they get a permission error instead of getting into udev rules or whatever. Especially with the growing interest in Linux thanks in huge part to Valve and Proton, I've seen very dubious habits of "just make it work" being ported over from Windows. Those guides are appealing too: one will give you 3 sudo commands, the other will do it proper but then you have a dozen commands or two to set up users and grant permissions and whatnot. The second guide, although the better one, isn't as appealing as the first one especially when you're lost, you just want the thing to work, and you're looking for simplicity.

For a lot of simple use cases, dropping privileges to nobody is simple and easy, no need to create new users. It's not horribly insecure and it's better than root/your own user in terms of blast radius. If there's just one service occasionally running as nobody, it's really no big deal, you just shouldn't run everything as nobody. Plus, people have the tendency of not reevaluating their problem when it grows, so it may start with a simple web server that doesn't need anything, but then you start needing to do more, and the "run the web server" part is mentally marked as done and final, so people will start granting nobody access to more things instead of taking a step back and reevaluating and upgrading their service to a dedicated user with dedicated privileges. Then that leads to privilege creep for a user that's supposed to have none.

The main issue with running more than one thing as nobody is, on Linux, users have the ability to debug their own processes. So maybe your app running as nobody gets exploited, but since you also run NGINX as nobody, now they can hook NGINX and dump TLS certs from it even if the actual files are owned by root and it dropped privileges: it still needs to have it in memory to operate, it loads the certs as root then drops privileges.