Still, to switch back to the previous point, it seems it's more a divergence between using markup or code to design a document. Both have valid usage and benefits depending on your case.

In my case and my apps, I often need to handle complex conditions that fits better imo in procedural code (complex invoices and agreements). On other cases (reports), I prefer to use a markup language.

If your app is a web app this is a no brainer, the users browser could simply do the print or PDF conversion as needed.

I do see a use for more direct libraries in native apps, although if every native client had a browser control with full print CSS support even then it might not be such an issue.

That's arguable, IME (and also a better UX), most would prefer to just get the PDF file which just one click than to deal with additional browser dialogs. No everyone knows how to do print-to-pdf or even know it exists.

Or do you mean browsers expose print-to-pdf functionality as an API?

If you serve a PDF you still need to hit print or use dialog to save, you can use a headless browser server side to serve that if needed.

I do think browser could use better print API's but you not getting around that with server side PDF's unless the server direct prints to on site printers or something.