Because it's a meaningless obstacle
Putting an upper limit on compilations is like telling a car manufacturer that they must build a new supercar, but are only allowed to test drive it a few times.
This means that you're pushing your developers/mechanics to theorize about whether something would or wouldn't work, instead of actually finding out.
Theories are really just educated guesses; so do you genuinely think that guessing more often will achieve a better result than testing more often?
Because that's not the purpose of education
Especially in a hands-on field such as software development, the goal to learning programming is to keep trying until you stop failing. That inherently means that failing (and thus needed another compilation in the future) is an inevitable step in the process.
You seem to think that compiling often is indicative of a "bad" programmer. It isn't, but let's explore that assumption.
What exactly is your perceived problem with compiling more often? If a "bad" programmer is able to deliver the same end result in the same amount of time as a "good" programmer, does it really matter whether they compiled often or not?
Clients/managers tend to not care about how a programmer achieves their goal, they only care that they achieve it within the set parameters. If anything, I'd be more willing to hire the programmer who continually fact-checks himself (by compiling), compared to the programmer who assumes they know what they're doing (rarely compiling) and thus will get stuck needing to retrace their steps afterwards.
What you're suggesting is the equivalent of not permitting students to redo their calculations on a math exam. You're trying to teach them the exact opposite behavior of what you should be teaching them.
Because that's not how it works in a professional environment
Once you get to the stage of being a self-sufficient developer, there is still much to learn. One thing that junior developers often do wrong is down the problem into sufficiently small and simple parts.
In short, it is better to build something with 50 simple components than it is to build it with 10 moderately complex components.
Cleverness can be damning as a developer. When you're developing something, you understand the ins and outs, and you might find a very clever trick/workaround that may seem counterintuitive at first but actually solves your problem nicely. This can manifest itself in different ways: overly terse syntax, lack of accurate naming, an overly complex algorithm, lack of self-documentation, requiring specialized knowledge of a particular tool/library, ...
However, your cleverness can be your undoing when you (or someone else) needs to reevaluate this code in the future. If there's a bug, it will be hell to find out where the bug is located.
But even when there is no bug, e.g. if the requirements change, you will need to be able to pull the existing logic apart to introduce your changes.
Putting a hard limit on # of compilations wrongly incentivizes developers to only compile (and thus test) large changesets. When anything goes wrong, it's very hard to pinpoint where exactly it went wrong.
However, if you compile (and thus test) small changesets, it's very easy to see where it went wrong, as there is only a limited amount of changes that have occurred between the last (working) version and the current (failing) version.
This is the core argument for using unit testing and continuous integration. Developers are urged to take the smallest possible incremental steps, so that their code can be tested every step of the way, thus making it easier to find the source of a bug/error.
Since there is no purpose to retesting without recompiling; if you want to test often, you must therefore also compile often.
I've developed a pretty bad habit of programming by permutation/shotgun debugging and in my first few months of Programming and even after 1.5+ years I still fall back to it sometimes.
When all else fails, shotgun programming is the most reliable method of figuring things out.
That is not to say that shotgun programming should be your primary development approach, as it can lead to time wastage. But when all your clever logging and theorizing fails to solve the problem at hand, shotgun debugging pretty much guarantees that you can take (admittedly slow) steps towards finding the solution.
As much as I am pro-shotgun (in certain cases), I do concede that wanton shotgun debugging can be used as a way to brute force a solution and avoiding having to understand the problem, which is counterproductive in an educational context. But this is part of a bigger issue that is not easily preventable.
For example, some students may rely on StackOverflow as a snippet repository and avoid having to understand the snippet or why it works.
To be clear: as a software developer I use it as a snippet repository as well, but I use it as a shortcut or not having to reinvent the water, not as a way to avoid having to learn the core skills required.
The issues of students writing code that works but they do not understand why (regardless of whether it's copy/pasting or brute forcing a solution) is not something you can address with a simple test. This is where oral exams are most useful, because you can very quickly gauge the difference between a student who found the right snippet, and a student who understands the core problem and how to approach solving it.