Почему пиры wireguard не видят друг друг без sysctl -w net.ipv4.ip_forward=1?

Да, в этом сезоне завоз годный, прогресс мировой неминуемо повышает качество.

на одном интерфейсе wg0

На разных интерфейсах wg0, у каждой машины он свой, индивидуальный. ^_~

На сервере ж один, там два пира прописаны.

А почему тогда пингуется сервер - 192.168.50.1 ?

Потому что туннель точка-точка работает.

Почему тут нужен форвардинг?

Потому что ты организуешь топологию типа «звезда». Есть центр, к нему подключены клиенты. Когда ты посылаешь пинг от клиента A к клиенту B, пакет ныряет туннель на стороне A, выныривает на стороне сервера, сервер видит не свой IP адрес у пакета и отбрасывает его. Чтобы он его послал по следующему сегменту, то есть через туннель от сервера к клиенту B, нужно включить форвардинг.

Дядя Вася приходит к дяде Диме и просит его передать письмо тете Маше. Вашими словами: «Почему тут нужен форвардинг» если «Они живут в одном доме»?

В Ethernet-сетях хосты связываются между собой на уровне Ethernet (L2) в пределах своего L2-сегмента (также называют Broadcast-сегментом). Они передают Ethernet-фреймы между MAC-адресами без ограничений, независимо от того, какие IP-адреса в них указаны, и не ограничиваясь только IP-протоколом. Вы не сможете заблокировать передачу данных между двумя IP-адресами внутри Ethernet-сегмента средствами iptables со стандартными настройками, даже если у вас программный bridge (для этого необходимо активировать отдельную опцию), потому что пакеты не нуждаются в маршрутизации на уровне L3 и не попадают в netfilter.

Опция ip_forward включает маршрутизацию на IP-уровне. WireGuard предоставляет только L3 (IP)-туннель, реализовывая L2-логику внутри самой программы, ядро про нее ничего не знает, поэтому между участниками необходимо маршрутизировать пакеты на IP-уровне. В OpenVPN, к слову, для этого есть опция client-to-client, реализующая маршрутизацию внутри самого VPN-сервера.