I would say that the same does apply for native code as well.

Developing native code means writing code, reading code and documentation, and interacting with the build system / debugger. Those tasks need to happen directly on the developer's workstation, but not the actual building and execution/testing of that native code.

This is better done in an environment with known state, i.e. either an isolated local or remote VM that will have the environment set up as required for production, and likely multiple different, incompatible environments, or some external hardware for many use cases of native code. Best practices and a modern toolchain would imply things like reproducible builds which you can't really have if you're building and running C or C++ code directly with whatever setup and libraries each developer has on their own workstation, no matter if they're on linux, windows or mac.

You need both a reproducible build environment and an environment that your IDE is tightly integrated with - at present IDE-VM integration isn't quite good enough for the same environment to act as both. The closer together those two environments are, the less common bugs that can't be reproduced in the dev environment will be, and such bugs are the hardest to deal with. (You still have to be capable of dealing with them - you'll get them even when running the same OS in both cases - but the lower the rate, the better).