Per RFC-1 which defines RFCs, there isn’t an RFC-specific escalation path. Indeed, your argument from suboptimization applies here: I don’t want to establish an escalation policy for 1 practice, when the problem described (suboptimization) applies equally to early access programs, change logs, deprecations, or any other changes to the ecosystem. Generally speaking, there never has been something I can point to as a formal escalation process but it has been and remains an option to open a developer support ticket and ask for management conversation. There are also many other paths to reach management, including DMs here in CDAC.
That said, I don’t know that your appeal to suboptimization is appropriate for the case of ARIs. Custom URIs are nothing new to the internet. AWS, Azure, and Google all expose some form of URIs, many of them custom. If we had the “architectural committee or something” to which you might appeal, I suspect we would have switched to ARIs much earlier, rather than the other way around.
I think you anticipated my assertion given your 2nd point, “unless there would also be a plan to migrate other parts of the Atlassian event system.” And, I think the problem is really with IDs in general because an event is likely to trigger the need for additional queries, and you’re saying the overhead of ID switching is intolerable (at least in the long-run). On this point, let me confer with @JustinThirkell (who is an architect) and we’ll respond within a week.
In the meantime, I think there is an implied “conservative plan” wherein we would only introduce ARIs when we have no other choice, so as to minimize the disruption to current API clients. Thus, the burden is on new APIs (like those described in RFC-29) to provide bridging. It’s clear from your line of reasoning that you either think that we have another option or that you don’t believe in this “conservative plan”. Perhaps you could elaborate on why you are pressing for a more explicit plan?