You've described a scenario where your process overhead is actually only around 10%. That certainly seems adequate for most purposes.
You may be mis-categorizing prerequisites and dependencies as process overhead. By doing so, you have incorrectly determined that your process is wasting 80% of your available man-hours (or incurring process overhead of around 500%) when in fact your process overhead appears to be well below the 35% average for American industry as a whole.
Acceptable levels of process overhead are really just management targets, and will vary by organization, job sector, and project management framework. There is no single number which is ideal across all scenarios.
In a way, you're looking at things backwards because your question axiomatically assumes that writing code is the primary purpose of your project management process. It isn't. Delivering value in a predictable and controlled fashion is the raison d'être for project management.
In general, most of the additional steps you've listed as overhead aren't. As an example, requirements-gathering isn't really overhead since you can't deliver working code if you don't know what code to write, or what that code is supposed to do once it's written. Gathering requirements is therefore a prerequisite to writing the code; or, if you prefer to turn it around, writing code has a dependency on requirements-gathering.
Most of the steps you've listed add value to the project. They ensure that you are building the right things, and in the right order. That classifies them as prerequisites and dependencies, rather than waste.
While there's surely a technical definition, in practical terms process overhead is all the stuff that adds no intrinsic value to the deliverables, but is nevertheless necessary to the functioning of the project itself. Project meetings, project management artifacts, and project communications are often good examples of typical overhead.
Do the Math
You've defined a process that totals 5 man-hours per feature, of which only 30 minutes should be classified as overhead. You are therefore spending only 10% of your project time in process overhead. In contrast, a typical Scrum project often requires around 30% overhead for its processes.
Unless you have a specific business driver for reducing that number below 10%, I don't see an actual problem. However, if management or your development team feels that there is waste that can be trimmed, by all means feel free to see where you can make some incremental improvements without cutting quality.