As you've noted, when you're working on game mechanics, speed of iteration is critical. The longer the time between thinking of a modification and being able to test with that modification, the less productive you'll be, and the more distracted you'll become. As a result, you definitely want to be managing your iteration time.
For me, I find that my productivity really starts dropping off when the time to test a simple change exceeds about five seconds. So when you're experimenting to perfect the way the game feels, one of your goals has to be figuring out "how can I make a change and then be playing using that change in under five seconds". It doesn't really matter how you do it, as long as you can hold that iteration time down to about that level.
Lots of big modern engines (Unity, Unreal, etc) tend to do this by putting their editor inside the game engine, so you can make most modifications live, without ever restarting the game. Smaller engines/games typically focus work in the other direction; make the game compile and launch so quickly that it doesn't matter if you have to restart the game for each change; you'll still be in and testing before that five second period is up.
In my current project, it takes about ten seconds for me to do a small recompile, link, launch the game, and then reach gameplay (most of that is generating renderable world geometry when loading a saved game). And that's much too long. So I've created separate "testing" game modes which let me test different parts of the game without loading all the real game assets, so I can get in and out much, much faster; typically in about two to three seconds. If I want to test some UI, I can do that without loading into the real game. If I want to test rendering, I have a another mode where I can test that, again without loading up the whole game system.
I've seen other folks who have approached the problem by placing game logic into a DLL, and letting the already-in-memory game executable reload the DLL while the game is running, so you can rebuild the DLL and just reload it inside an already-loaded executable, so you don't need to reload/rebuild your game's art assets. This seems like madness to me, but I've seen it done.
Much simpler than that would be to specify game behaviours and/or configuration in scripts or data files, and provide a way to make your system re-load those files, either on demand, or perhaps just watching them for modifications, without needing to shut the game down, re-link it, and then start it up again.
There are plenty of approaches. Pick what works best for you. But one of the keys to successful refinement of game mechanic is extremely rapid iteration. If you don't have that, it almost doesn't matter what else you do.