>> Older VPN scripts used to override your default route in the main table when connecting to the VPN and restore it when disconnecting. Sometimes this wouldn’t work, and after disconnecting from the VPN you would be left without any default route at all.

> Isn't this the same problem the old VPN problems had though? If it fails to delete its two rules then your routing is still boned.

You're right, that's not the reason.

The real reason WireGuard doesn't use the traditional technique of replacing the default route is, straight from the horse's mouth https://www.wireguard.com/netns/:

  The most straightforward technique is to just replace the default route, but add an explicit rule for the WireGuard endpoint:

  # ip route del default
  # ip route add default dev wg0
  # ip route add 163.172.161.0/32 via 192.168.1.1 dev eth0

  This works and is relatively straightforward, *but DHCP daemons and such like to undo what we've just did, unfortunately*.

And right below that, is the reason WireGuard doesn't use the OpenVPN technique:

  So, instead of replacing the default route, we can just override it with two more specific rules that add up in sum to the default, but match before the default:

  # ip route add 0.0.0.0/1 dev wg0
  # ip route add 128.0.0.0/1 dev wg0
  # ip route add 163.172.161.0/32 via 192.168.1.1 dev eth0

  This way, we don't clobber the default route. This also works quite well, *though, unfortunately when eth0 goes up and down, the explicit route for demo.wireguard.com will be forgotten, which is annoying*.

Both emphases mine.