libqpdf also intentionally limits its scope to PDF structure, so doesn't address nontrivial content creation or manipulation (page content handling is pretty much limited to compressing/decompressing and parsing/unparsing the content stream).
Granted, one could probably build some of the machinery memory management in a simple way but it'd still need to be done and probably not be coherent with other native interfaces.
Wayyyy back in the day, before package managers were a thing, I had to write something to output a PDF via DLL calls and frankly it wasn't a bad experience. Possibly outside of what is in a 'modern' workflow but honestly wasn't too difficult. Just wrap it all in a class that only gives what you need and avoids potential footguns via validation.
Frankly it was easier than doing anything with Autocad's 'managed' libraries [0].
Maybe it's rose colored glasses for me, but .NET had fairly simple rules for most marshal bits so long as you knew them, although I will admit we didn't worry about 'performance' for the stuff I wrote and that can be a factor.
[0] - Microstation had a bunch of fancy COM hooks and exposed all of it to .NET in a nice way. AutoCAD 'managed' libs had all sorts of weird sorts of arcane rules and if you failed to follow them not only could you crash your .NET process but Autocad could remain unstable until you rebooted the PC... which is why I keep putting managed in air quotes.
If you're wanting to use a C library, yeah, you need to manage how you use that C library, this is true regardless of the language you are using, it isn't magic.
Having worked on some basic parsing of metadata from PDF spec, I would rather pay than have to code something myself. PDF is such a PIA.