My immediate reaction was to strongly disagree, provided you follow through and actually test with the minimal versions. So I contemplated a more nuanced recommendation: include the full latest version number, or test the minimal versions you use; but then I realised that writing the full version number doesn’t actually solve the problem of overly-broad dependency specifications in the long term, because it’s fairly easy to accidentally update your lockfile, after which you can encounter the problem all over again.
And so I say: if you’re not deliberately testing on minimal versions, all approaches other than exact version dependencies (like serde = "=1.0.130") are Wrong™.
It’s then a question of relative harms, and yeah, a patch-level minimum that at least matches at the time you first add the dependency is probably less harmful than an overly-wide spec that you’ve never tested.
But I think it’s important to realise that what you’re recommending only mitigates a bad practice, it doesn’t fix it. Only testing fixes it, because the bad practice is not actually the broad version specifications, but rather failing to test your minimum versions—for that is the cause of both of the problems you’re pointing out.
So now my inclination is towards this style of recommendation: test on minimal versions, but if you’re not willing to do that, include a patch number and never ever run cargo update, which achieves a result almost as good. I just don’t like your framing of it which is closer to “actively remove old versions even though they work fine”.
This suggests to me that there may be a need for improvements in testing minimum versions (of Rust and of dependencies; I would also note the pain that is the absence of consideration of MSRV in version resolution). You know how cargo publish checks everything builds unless you pass --no-verify? Well, what if it were to do a second round of building, on minimal versions of the crate dependencies (even if not of Rust)? This would seem a fairly easy fix of the whole problem, and I don’t think it should be controversial, either.
(I write all this as one who recently published a crate release depending on hashbrown >= 0.1.1, <0.13, testing at both ends of the range, and feeling good about the whole thing.)