I think there is some truth in using past experience to help you find bugs, but that is not a heuristic that will improve product quality significantly, because it’s nothing new. Everyone knows to look in the same area as last time, bugs are like animals in a desert, most of them will be around the same watering holes. But all you might find is more of the same low value bugs, a bit like dredging. Bugs and are often there because they are in functionality that nobody cares about and that do not impact the business.
To explore and find bugs that impact the business you need a map that leads you to bug watering holes that are not yet charted, and you need to find them before the customers find them. And that means looking in areas where an environmental factor has changed (an external stimulus of some sort.) Elizabeth H’s “Explore it” book on exploratory testing covers a few heuristics or tactics to employ, as well as tips on how to explain why and what you did, to your team too. Use past experiences to find new maps, but do this at the problem-domain level.
For example: I found a bug in text font sizes while checking product accessibility, so I then go hunt for LI8N/L10N bugs in case some languages don’t fit into the controls.