If you get visibly inconsistent results during the course of a printing session, I suggest you run fewer prints through your developer before replacing it.
If you start out by using a longer (but still within specified range), standard developing time, you will find that you will be much less likely to encounter
any visible inconsistencies through a moderate print run. That is the advantage of using longer times to start with.
The disadvantage, of course, is that the longer times increase the time required and/or decrease throughput, which in a
commercial environment decreases profit. Which is why higher volume, for profit printers use very short times, and either use developer one shot, or they use replenishment and carefully monitor results.
And that is why manufacturers like Ilford specify ranges of times, because the needs and preferences of users vary.
Within a reasonable range and consistent with the normal developer capacity recommendations, you have a choice of two options, both of which will lead to essentially the same results:
1) maintain the shorter minimum times, and replace the developer more frequently; or
2) use a longer standard time, and replace the developer less frequently.
The real challenge, and this applies to both options, is to know when to replace the developer. That is where factorial development helps you keep a handle on things, because it gives you some live data to base your decisions on.