That one wins by not bothering to conform to the PDF spec at all.
The spec is huge, and the insecurity comes from having to faithfully implement all its utterly insane features, like embedding flash files, executing javascript, rendering external assets, and so on.
The challenge is to decide which subset of those features you want to deliberately ignore.
Most of the esoteric ones are likely critical to obscure, in-house business applications created years ago by corporate coders lacking in sense. Adobe Reader obviously implements everything, and its the reference implementation, so it is installed in most businesses.
Unfortunately, business is the area most in need of security.
Some rich clients deliberately ignore parts of the format. For example, the Windows-based Sumatra client did. It seems to have been acquiring more features in the last few releases, and I'm not sure of its current state. But in the past it has been useful for example in that it simply doesn't run embedded Javascript. Or Flash.
That's been my personal approach, such as it is, to the need to deal with some PDF files from third parties. I look for the environment that does no more than render the static page content.
Somewhat akin to using NoScript in the browser. I only execute when I need to, and then from a source for whom I have some trust.
I recently had to clean up some business systems belonging to a relative whose employee ran an infected PDF. By avoiding execution, I was able to examine the PDF and show them how it was indeed the source of their problems.
Unfortunately, these "business users" still have limited will to learn the techniques to avoid such problems. I've made some impression, but the Adobe PDF format is still a time bomb ticking away in the midst of their organization.
I'll mention that, for casual browsing, I use an extension that redirects PDF URL's to Google's Document Viewer (while not signed in to Google). Again, I get (usually) the static view without having to trust or execute the file on my own system. Thanks, Goog!
(Note that I don't do the latter with documents containing sensitive/personal information.)
The complexity of the PDF specification isn't what's relevant here. Even if pdf.js were to implement all of the PDF specification, it would still be more secure than Apple's renderer, because it's written in a memory-safe language.
This is one of the reasons pdf.js is so important: it reduces the attack surface of the browser.
The spec is huge, and the insecurity comes from having to faithfully implement all its utterly insane features, like embedding flash files, executing javascript, rendering external assets, and so on.
The challenge is to decide which subset of those features you want to deliberately ignore.
Most of the esoteric ones are likely critical to obscure, in-house business applications created years ago by corporate coders lacking in sense. Adobe Reader obviously implements everything, and its the reference implementation, so it is installed in most businesses.
Unfortunately, business is the area most in need of security.
In summary: OMGWTFPDF!