What's the point, you can't debug or even run such an executable? What developer is just going to compile stuff without testing it? It makes no sense to want this.
For starters, Wine actually works really well. And beside that, time spent writing code is measurable in weeks while time spent running an executable to test or debug is measurable in minutes. The amount of time spent testing and debugging is a tiny fraction of the time spent coding. RDP/VNCing for one of them every second of the day can be a huge pain in the ass. Doing it for the other once in a while is a minor inconvenience.
Next time just say "I'm glad I don't have that problem" instead of "You can't possibly". A mindset like that ends up making you look foolish, because you'll be wrong most of the time.
Despite the negative tone, I think you are correct about the mentality that leads us to conclude that we have the simple solution for every problem and that others who can't see those simple solutions are clearly not up to par. Comments of the form, "Why don't you just...", usually end with something that doesn't fit the situation, just the mental model of the poster. Over time, and with enough experience, you learn empathy for other developers. You've seen enough adversity to know that we solve problems in different ways. I don't subscribe to absolute relativism, but we have to allow for the practical, not just the theoretical.
That said, we also have to be able to encourage others to present their ideas. We clearly can't grow if we don't hear and consider external ideas. It's a difficult balance to strike.
You can run it on a remote computer (or a VM) and debug it from an OS X front-end that connects to the remote-running debugger over the network. It's a pretty common technique, gdb has had it for, what, fiftenn? Twenty years?
Maintaining two separate development environments, on two operating systems that you have to boot into separately is very annoying. Developing for an operating system other than the one you're running is about as old as the personal computer, I think :).
The remote computer is often good enough to run an application but way too slow to productively compile a large codebase on it. Besides, you don't need to maintain two development setups at once.
This is a niche situation only because Microsoft's tools make it a niche situation. It's pretty much how all embedded software on this planet is developed (except that the network is replaced by a serial connection on the lower end of the performance spectrum, of course). In nix world, it's a super-common situation; e.g. at $work, where I write software for networking equipment, no one seriously expects that I'm going to compile stuff on the routers that ends up running that software. Most of them are capable of the required heavy lifting (they have CPUs in the same performance class as a pretty beefy desktop), but why?
We're not talking about just a compiler here. Nobody says "You should try CL.exe, it's really awesome at compiling!" No, they say "Visual Studio is the best C++ IDE you'll ever use." Which is true, but not because of the compiler. And without all the Windows-specific libraries, intellisense and code analysis tools that are second-to-none can't work.
What's the point, you can't debug or even run such an executable? What developer is just going to compile stuff without testing it? It makes no sense to want this.