Is that an essential part of the original design though, or was it a DoS-mitigation mechanism? If we instead mitigate DoS/jamming via a monetary solution, perhaps we don’t need onion messages to be as lightweight.
I’d also note that a completely jammed onion network also defeats the original point (to an even greater degree), so this may be a worthwhile tradeoff overall.
We can do batching, but I’d rather not if we don’t have to. There’s less state to manage without batching, and the whole protocol becomes simpler (and overlaps more with up-front fees for HTLCs).
The future benefit is getting to route more onion messages in the future. Nodes that drop messages will be routed around, leading to less fees in the long run.
Also, as you mention in the footnote, sometimes the current onion message corresponds to a payment flow that will pay fees to the routing node in the near term.
Why not? If an onion message couldn’t be routed across a path (tiny liquidity requirement, small resource usage), it seems highly unlikely that a payment could be routed on that path (larger liquidity requirement, larger resource usage, consumes a scarce HTLC slot).
I’d expect onion message fees to be adjusted automatically. If the node is getting overloaded with onion messages, it raises its fees. If it has unused capacity, it lowers its fees. No need for static magic defaults or for the end user to do this manually.