The problem - at least with most of these offerings - is that they need to modify the schema in ways to ensure they have some kind of referenceable 'key' field for managing the syncing up between the two servers, and that typically involves adding extra columns and constraints that then cause parts of the application and upgrade to be broken when it runs SQL to modify the structure of the schema objects (views, indexes, tables).
Should there be a truly transparent mirroring/replication offering that doesn't cause or require changes to the schema (especially on some tables with no primary keys - for which we have some - as this is where those technologies are most likely to modify the schema if not everywhere else too anyway), then it may well 'work' even though it won't strictly be something we have that is supported.
The things I have been describing though are real examples where these configurations and the software driving them have caused PPM to break and are not just hypothetical. But something that just uses the data from transaction log files and makes zero changes to the PPM schema might work.
One other issue to consider now with the DWH schema is that sometimes transaction logging is intentionally disabled for some operations (from within the code), and that would likely violate replication/mirroring technologies from working correctly.