It's a good question, but also a begging question.

On the one hand, yes: keeping security out of the middle of the network and pushing it to the endpoints is something that The End To End Argument In System Design predicted several decades ago, and is (to my eyes) clearly the right design principle for this problem.

On the other hand, the endpoints doing the encryption are also going to be COTS equipment sourced from major industrial centers and acquired at a scale that probably precludes individual hardware verification, at least at the price point that enables their widespread deployment today.

There are things you can do in an evil router that encryption and integrity protection don't mitigate.

Adding unique delay variance patterns for packets from a specific set of packets (source address, payload type etc). This makes it easier to detect and follow interesting traffic.

You can also copy certain packets, divert packets, inducer errors (to cause resend that in turn triggers repetitions in higher layers that might be usable for info leakage from the protection mechanism.

The router really is your friendly, silent mitm helper gnome.

You have to trust that router delivers your packet to an endpoint. Encryption doesn't prevent that. And unless you're delivering extra packets to mask your control packets, it's trivial for the router to make drop decisions on packet flow data.

But dropping packets is not supposed to harm because it can happen anyway for various reasons. And a malicious router dropping packets is guaranteed to get some attention sooner or later.

It depends on the drop it causes. If it only increases the drop rate for certain streams than detection will be harder to notice. And of course the perf counters can't be trusted thus making the detection harder.