The flip side is that because the industry has converged on just a few embedded scripting systems (JS, Lua, etc.) we can concentrate our security hardening efforts on these few engines and benefit everyone. If PDF, like PostScript, were its own custom thing, it couldn't have been able to benefit from this hardening. In the end, JS was a fine choice.
The concern isn't that it was JS, the concern is that there's a scripting system inside of PDF at all. Why? What? Form validation is a lousy excuse because forms themselves were a bridge too far for the format. Why do we need to be able to validate them?
I knew PDFs could be dangerous, but I didn't realize it was because they're intentionally designed to allow embedded scripts.
I don't think forms are a bridge too far, it was very common that forms were provided as PDF and it is more convenient for the sender and receiver to fill the fields on a computer for readability, etc. before printing.
However, forms could be handled by a very simple DSL that would be easy to write a safe interpreter for.
JavaScript is already a simple language. There's no requirement to have a JIT even. What makes you believe a custom language would be any safer or better in another way?
IMO the parent commenter leans to a validation-specific DSL, opposed to JS, not only because the language complexity itself, but also due to the usually wide range of objects the script engine gets access to. like title bar, URL box, window decoration, placement, mouse pointer, keystrokes, etc. in web browsers. i worry what it has got or will get access to in documents?