It would be useful more as a tool to help migrate away from e-paper workflows, i.e. emailing PDF scans of legacy paper forms, and towards smarter architectures.
For example: suppose a customer with a workflow where the customer fills out a PDF form and emails the completed PDF to an externality (e.g. supplier, other department whose workflow they can't control, etc.). So you build a modern UX that uses the PDF API to fill out the PDF with the data from the UI, and then email the PDF to the externality, just like before, so that they're on-board with the new UX (since it doesn't affect them at all).
Once you build the new UX, you can then sit with your externality and figure out what they need in order to hook into the modern system. After all, they benefit from a single queryable source of truth, just like anybody else, and the customer is generating that source of truth when they put their info into the UI which ultimately emails the PDF. Once you build the UX for the externality, there's no need to retrain your original customers - they can keep using the modern UX you built for them before. All you have to do is update internally to make sure you're updating the sources the externality's UX expects, stop using the PDF API and emailing the results, and your migration is finished in a pretty simple way that is transparent to the customer.