This is a somewhat common technique for tracing the value of a variable backwards in time in native code, particularly in the presence of buffer overflows or other memory corruption. When debugging, you find out that a variable has a weird value, a value it could never have according to the code. So you put a hardware breakpoint on the variable's address and restart the program. Play around with the step count on the breakpoint, and you can find the write that messes things up.
It only works when you can reliably reproduce the same execution steps every run, including heap addresses. And ASLR breaks the technique.
ASLR also tends to make buffer overflows and other memory corruption appear randomly rather than consistently.
I've needed to do this on literally every single program I've ever worked on, and I've even missed them a few times in C#...
Not as much of a problem if you have debug data.