The problem is mainly that the effort spent to fix the nav is often too much work compared to using some tricks in hammer to just force the engine to generate a correct one. There are often small tricks you can perform to change the way a nav is generated. Sometimes just putting a 8HU clip at the bottom of the staircase to get a slightly diffirent start angle can be unnoticed while playing, but already give the nav generation a diffirent behaviour.
Do note that you arent going to just compile your level once for testing, you should do it many times and fixing those bugs 50 times is realy a lot of effort for something you might solve permanently in 5 minutes spread acros 30 seconds between each test compile for visuals. And dont say 'ill just do it when making a release version', because that indicates you arent testing it enough, or are spending a massive time on it at a very late state.
The thing that im talking about is bots getting stuck behind a corner, things that can be rare anyway but can involve a lot of testing to fix. Trying to find a permanent solution of which you no longer have to care about is better. Hence solving these things in hammer can be far more efficient.
Sure, some things require nav editing in the end anyway (some maps just require it). But avoiding any editing work is more convenient anyway. And also are less prone to mistakes during editing.
Do note that skullcove had about 20 minutes worth of nav editing each time. Which in the end has resulted easily into over 10 hours! Its not a little time you save.
More than "nav_generating" I think it's better to "nav_analyze". It keeps suggesting you to use it whenever you save non-minor changes to the .nav file, either an existing or new one.
nav_analyze is normaly the last step of a nav_generate. Its what considers the vision within the map and where bots can stand at a safe location compared to an other square. It contains extra information which the game requries for a good AI. A few things to consider it analyzing is the fastest path between nodes at an X distance, wether a jump down area is actualy safe to jump down from (bots will avoid paths that make them take damage from trigger_hurt), extra hints about dangerous or safe areas (although mvm doesnt use this info), and probably even more info i cant even think about. These are things you cant do when editing the nav yet are vital. Thats why each edit requires this.