I sent it, then continually followed up on the status of the points made. Some changes ultimately did get integrated because of it, I think calling the bluff forced someone to actively read, think, and respond to it, even if it wasn't leadership, they had someone else spot check and agree/disagree on points.
I think that it requires acknowledgment that there are two sides to such issues; as someone who is on the side that typically ends up having to handle the majority of the busy work to get many proposal through in my company I absolutely want the proposer to make the effort to figure out the stakeholders/costs/challenges for their project as well as answers. I'm willing to __fill in gaps__, but I don't really want to be having to do the basic legwork for someone else's project.
I don't mean to sound like I want to stifle inconvenient creativity; it's certainly not the case, and when someone has really taken the time to make some new tooling/project with benefits and acknowledges the costs involved, I'm more than happy to champion such projects.
But when someone just has a desire (or disparagingly, a whim) to change stuff up because it simplifies their workflow and they expect someone else to handle all of the communication of their project without even giving me the courtesy of doing such research, I cannot deny I approach such proposals negatively as I feel a bit used and I think that the expectation is "I want this, make it happen", which is not my job.
Similarly, I find myself encountering persons who expect that I and the rest of the company will magically intuit the importance of very niche projects without being willing to take the time to simply explain the pain point they wish to address. I'm not even talking about deep technical details here, but simple things like:
"We spend N amount of time on task X"
"I have an automation workflow that will require Y hours to implement, but N is reduced by Z [time value]"
Instead, the presentation is "I want to implement this automation workflow; what do you mean explain the value? Can't you see it? Why are we so caught up in corporate bureaucracy?"
I'm all for reducing N as much as possible, but if I myself can't explain why spending Y is vastly cheaper than N, I have no confidence in my ability to convince others that the cost of Y is worth it.
I've truly been on both sides, and it is some work to justify a change, sure. Formal proposal documents are a bit much for my taste, but whether we like it or not, C-Levels aren't going to read your code and they definitely aren't going to read a 2000+ word stream-of-consciousness email describing the project in an unstructured way (much less any git readme.md files). The impetus is on the person proposing the change to at least make an effort to convey the reason for the change to the relevant stakeholders.
Requiring some basic rigour to the thinking is good though.
Since time can only be spent once, you are essentially picking between a quick&dirty prototype and a nice document.
The document invites a bikeshedding session and consumes reviewer time, the prototype often allows you to immediately see whether the idea is worth pursuing, it may directly deliver a part of the benefit of the completed solution, and most importantly, it'll show the actual weaknesses in the design and the real constraints you have to deal with in a way that a theoretical review can't.