I don’t know that this is true, it’s only my own theory:
The new fabric pages seem to use an entirely distinct renderer from legacy pages. As I understand it, the new ADF page format is used to directly render fabric pages, but the legacy SFXML renderer still exists to service old page content. A translation engine exists to convert SFXML and ADF content between one another (but the conversions do not map 100% due to the fact that the two feature sets do not overlap perfectly, by design). As far as I can tell, the REST API only supports rendering using the legacy rendering engine, judging by the HTML it produces. This is also true for static content macros – feeding SFXML into a fabric page by way of a static content macro still awkwardly produces legacy-style HTML. The dual rendering engine set up inside Confluence now seems to be making for odd mixed-mode HTML combinations which appear to be hard, if not impossible, for vendors to exert control over. All of this makes me suspect that the PDF exporter uses the legacy page renderer. I also suspect that this may be due to the fact that some of the “new” web components used by AUI and AtlasKit don’t seem particularly well suited to PDF (or REST-based HTML) rendering (though I could easily be mistaken there).
This dual renderer situation is making our life tough for some of the static and dynamic content macros we have. I’ve been told over time that they will eventually phase out the legacy renderer, which makes it even harder to stay on top of this leaky internal transition as things change. We have requested API help to allow us to tell what kind of page we are rendering content in and for stylesheets to help make that content look correct for the parent page, but to no avail yet.
Again, this is all just my own theory mostly reverse engineered from our experiences with these macros and the REST API, but I have had some confirmation of the rough shape of the theory from some Atlassian engineers and PMs.