Of course, an actual PEP or RFC, once written, is a very good starting point for that kind of standardization. That wasn’t my point though - it’s the action of requiring that which is the “soft no”, not the PEP or RFC itself. The argument is that if a feature merits larger discussion, it ought to merit a larger proposal (and how that would fit into the existing language) as well, not just a “I would like X please”, because those kinds of requests very quickly run afoul of hidden assumptions various people participating in the discussion end up making (through no fault of their own - that’s just how communication happens). Clarifying that up front in a PEP or larger RFC or JulEP can make that easier.
I attribute much of that to the general lack of direction in how feature requests would like to be handled, see e.g. here, here or here. There just isn’t any form of consistency or overlook by anyone, and hence getting a higher maintenance (but presumably much lower signal-to-noise ratio) proposal in the form of a JulEP off the ground is very challenging. We thus arrive at the current situation - feature requests or RFCs or similar go “wherever” and are picked up/commented on by “whomever”, implemented by “anyone willing to spend the time” (only to be then told once a PR is opened that, as implemented, “triage doesn’t like it”. Much of the time spent implementing something larger could be avoided by just talking about the thing ahead of time, and actually planning for where things should go).