HashLife uses an awful amount of memory, that's how it gets away without having to compute things - the answers are pre-computed in hashed lookup tables. This is significant for anything remotely complex.
Plus, the hashes would need to change if the model changes. That is, the entire search space would need to be re-hashed to X future steps anytime the search space changed - e.g. walls were built or floors were placed, thus changing the entire search space.
Also, it's not suited to non-local stuff like doing path searching on complex spaces. The initial hash would have to store every possible route, from any potential point to any other potential point before any single path could be computed. This would be much more overhead and memory needed than just creating paths as needed. You can't just pre-hash that like you can with a simple system like Conway's Life, where all interactions are local and there are simple cell-based rules.
---
Anyway, we can't really claim that the search algorithm lacks this or that, since nobody has seen the code. JPS is just an adaptation of A*. And DF probably already utilizes this. When I open a doorway between two large areas there is a significant game pause. Most likely there is meta-data about pathing being computed when this happens.
Even with stored-paths, the fact that forts are dynamic means there will always be pathing overhead. You just can't store every possible path for 10000's of squares, and even then you need to check that the quick-and-dirty checkpoint path you've decided on is the actual shortest path, so you need to calculate other potential paths at least to the point that they are clearly worse.