The difference is that you run only trusted native applications with the ability to check their source code, while you are visiting untrusted sites which often have obfuscated javascript.
I think that it would be a better comparison between a pdf file and the web: pdfs files can't do the same or more.
And I would argue it is harder for the average user to view the JavaScript inside PDFs: on the web just right click and choose Inspect Element right in the browser; for a PDF you'll have to use specialized tools to decode the myriad encoding schemes inside a PDF. The average JavaScript developer doesn't know how to extract JavaScript from a PDF.
While it works on Chromium it does not seem to work in xpdf, pdf.js nor any other pdf viewer that I tried. It seems that JS, flash, etc inside pdfs are proprietary, useless, and potentially dangerous adobe-only extensions that nobody else implements and nobody uses. It's just that Chromium happened to have a JS engine so they decided to let JS inside pdfs to be executed with a very constrained API (which can't do anything malicious probably - unless a bug is found in its JS engine).
My point still stands: I do not expect a pdf document to be able to do anything like the djsumdog's link and neither do most people. If a pdf document was able to do anything like that I would consider that viewer as broken.
> The average JavaScript developer doesn't know how to extract JavaScript from a PDF.
I think that it would be a better comparison between a pdf file and the web: pdfs files can't do the same or more.