* Use a few bullet points to put attention on the main points you want to convey.
* Without going overboard, use a tasteful amount of graphic design (bolding one key sentence or whatever).
* Break up a giant nuanced email into sections.
* If something is critical, make it visual: a picture, explainer video, or an infographic can be really useful for something key.
This is harder than it looks. A quote attributed to Mark Twain is "I didn't have time to write a short letter, so I wrote a long one instead." It's a lot easier to go overboard than to distill what needs to be conveyed into the core elements.
Hell, I've learned not to ask more than one question in an email. The first one is the only one to get answered.
How hard would it be to have a shared todo list where the team can put every blocking question which needs answering, and everyone who needs to answer can either do that or delegate the decision or approve skipping it? (And I don't mean a sluggish Jira / Electron / Teams / helpdesk which needs 50,000 fields entered to raise a ticket, either).
I suspect it isn't done because nobody can usefully make all the decisions which other people want to push off onto other people, it would take inhuman amounts of time and attention. And that part of the reason "answering only the first question" happens is to drop most questions on the floor, with the idea that important ones will be raised again, as a way to filter out the huge number of unimportant questions. And as a way to deal with the fact that answering one question can change all subsequent questions - if the answer is "that's waiting on finance approval" then it might be about to have a budget cut, or be cancelled, or be delayed until a new financial year, and answering other questions is a waste of time.
Still, for when the other questions are needed, it should be something computer people, programmers, IT specialists, can have machines keep track of without absolutely awful interfaces - and maybe involving automated email and replies if needed, like forum posts and newsgroups have had for decades.
(for PRs its the joy of having a sequence of dependent changes, and needing to make sure people review them step by step even though the whole packet is done).