The main problem I've seen with this strategy is 'funding' for the new system gets pulled half-way, and there's no time remaining to refactor the old system. Fast-forward a year later, someone else may try to write a 3rd refactor using a different 3rd improved system design. Now that project also stalls out due to project pressing concerns. Now the codebase is polluted with different systems that require more training to work with, more lines of code to cause bugs (mixed frameworks), and generally a headache. I still think the Stangler pattern is a good one, just make sure you get enough leeway to reach the 'strangler' moment where most of the old code becomes deprecated and removed.
This is known as the "lava flow" anti-pattern. I kind of like the visual imagery of the two. With the strangler pattern, you have new living pathways to deliver functionality. With the lava flow anti-pattern you have petrified remnants that lead different places, but which have died.
From my own experience, when you take over a project that has attempted the strangler pattern, but got cancelled the key is either to continue it (holding your nose if you don't like it), or remove it and go back to the old infrastructure. If the new pathway is better than the old, go with it until you can remove the old one. Even if you have a new super zappy way to do it, resist introducing it without "finishing" what what started earlier (one way or another).
At my last company, I headed the Engineering org and was told by my CEO that there was was no time for refactors of our monolith (and not a good one at that...access to HTTP request all the way down, for example) or anything silly like that, so we went a very similar route. We did what we called the zombie rewrite, which was an inside out refactoring that left no changes on the surface.
Step one was to slowly rework things into logical services that still relied on the underlying legacy code. Eventually, we got to the point where cross functional domain logic was accessed via logical services rather than direct use of classes in other domains. Once we accomplished that, we slowly worked back down to understand, optimize, and refactor legacy code in digestible chunks. The final stage was to work up to the REST API level to create a more sane implementation of the web bits that preserved existing behavior.
It took the better part of a year to do all the work, but by going piece by piece (which allowed for understanding some wonky code), we had very, very, very few regressions and minimally impacted our overall ability to still deliver on the roadmap.
