This probably made sense back in the good old days when disks were slow and memory expensive so you couldn't cache much. These days, it's a misfeature verging on being a bug.
And I don't think it can even be disabled.
Could this be the persuasion of one who subscribes to the school of thought that most, if not all, of the problems computational may be dissolved by the deft application of more RAM or more MHz or more Moore in general, to the pertinent parts of the technological apparatus involved?
If so, please be advised that upon consultation of the relevant materials, or perhaps by hiring a consultant to perform such consultation, one might be apprised of a configurable asset of this exact designation; and furthermore, that a method of automatic profile-based customization might also be discovered. Thus one, presumably, might draw upon the resources of a competent systems administrator in order to execute said design by carefully encoding the user's .bash_profile (and .bashrc) with the invocation of set +h.
*nix users often do not learn of this feature until years later, if ever. They don't need to. This is just a minor issue among the many bigger design problems
No, the path cache is not a bug, it's an overall improvement. If you have better ideas, please, do let the world know! Be sure to take all aspects into consideration, though. While RAM sizes have increased, so has the size of a typical distro. Weigh upon the implications of having e.g. NFS mounted /usr. This is certainly not the only case where user actions or interactions may subtly and surprisingly impact the working environment. Say, terminal report sequences getting stuffed into shell input, etc.