This severely limits valid use-cases because users have become acclimatized to relying on in-browser viewers embedded in a web app (e.g. that of Google Drive, OneDrive, Dropbox, HubSpot, etc.) or built into the browser itself. These almost always are highly minimalistic implementations.
For example, in a previous company, we wanted to provide our clients with a PDF guide which had in-document jump links (which, in the world of HTML, would be called "URI fragment links") and also a functional table-of-contents in the form of PDF "bookmarks."
But I ran into two major blockers:
First, Microsoft Word is almost the only non-Adobe product which is capable of producing such PDFs, and only when _saving_ as a PDF, not when _printing_ as a PDF (which reduces the document to little more than would be printed on a page).
Second, the only in-browser PDF viewer I could find which supports these features was, somewhat surprisingly, the one which is provided in WordPress. It supports both.
A similar story played out among mobile and desktop PDF viewers which weren't Adobe.
So for our beautiful, accessibility-compliant, featureful PDF, we had to provide very strict instructions on how to view it properly. When provided for viewing online, it _had_ to be hosted in a WordPress instance. And when offered for download, it _had_ to be accompanied by loud instructions explaining the situation and requiring users to install the free Adobe Reader.
You likely dodged a bullet by avoiding the use of any advanced PDF feature.