you could with anti-exploit techniques (or within windows itself) hook VirtualProtect and such functions to check if its not making the stack executable. Also you could check it on process startup. However, it won't solve much, because then you simply slap it on the executably mapped heap region and do it from there?
There are cases for allowing memory protections to be changed, and because of that, it's possible and people use it. (code-generation / JIT etc.)
the stack being executable used to be a big problem, for example in 1995 with things like stack overflows running wild, but I think those have been largely mitigated by having things like stack canaries/checks stop stack overflows from being done (stack smashing detected!). those canaries were introduced around 1999 or so, and yes there are ways around it (rops/jops etc.), but not through the simple overflows from 1995.
I am all for not allowing it, but admittedly, that's likely some impractical utopian stance on the matter regarding the current use of operating-systems.