Popular VPN/mtu settings seem backwards to me - Where do I have this wrong?

I must be misunderstanding how to use mtu with VPN's. At this point, I am focused on a UDP VPN with UDP traffic inside of it. I recognize the man page says:

--link-mtu n Sets an upper bound on the size of UDP packets which are sent between OpenVPN peers. It's best not to set this parameter unless you know what you're doing.

I'm not hoping for answers of "do what everyone else does, use fragment and mssfix". I'm instead hoping for "know what you're doing" knowledge.

There's:

• link-mtu : The maximum packet size ignoring the tunnel, including VPN overhead ("double" IP/UDP headers, encryption/etc.)
• tun-mtu : The maximum packet size for the tun adapter, inside the tunnel, and ignoring VPN overhead.

Several popular VPN's and many examples online set the tun-mtu to 1500, for inside the tunnel. This seems completely backwards to me. When I look at what's being sent out to the internet in wireshark, during large transmissions, I see fragmented packets alternating between 1500 and 85 bytes. This looks to me like unnecessary fragmentation, with increased overhead and twice the chance for transmission error.

The maximum non-jumbo Ethernet frame size is 1518, with 18 being Ethernet headers. So, the maximum mtu that could ever be used when transmitting across the internet is 1500. If a higher mtu is used, the packet either needs to get fragmented by the device (probably customer's router, but potentially at the ISP) handing it off to another with 1500, or it will just get dropped. Everyone's maximum mtu across the internet isn't 1500, it can be less.

FWIW, my physical connection supports a 1500 mtu. (I can ping outside with don't fragment outside with 1472 bytes, plus the 20 byte IP and 8 byte ICMP headers, and 1473 bytes fails as expected.)

Shouldn't the goal for a VPN be to make the actual across-the-internet packets a maximum of 1500, to maximize packet size while preventing what could be a single packet from being fragmented? (Or, maybe a bit less if they wanted to do so since some customers will have less, at the cost of those who do have 1500.)

I have this feeling my reasoning must be flawed, because the man page suggests not using link-mtu, and several popular VPN's (who should "know what they're doing") make their config files include:

tun-mtu 1500 tun-mtu-extra 32 mssfix 1450 

When I connect, it shows adjusting link-mtu to 1657, and sets the new tun device mtu to 1500.

Shouldn't a VPN should set link-mtu to a maximum of 1500 or a bit less, allowing OpenVPN to calculate a tun-mtu of a bit less, and setting up the tun adapter with the appropriate mtu, also a bit less? (I'd think these would be the same, but as I'll mention in next paragraph, they aren't.)

My reasoning seems to make sense, because if I edit the config file to have link-mtu 1500, OpenVPN says tun-mtu is 1375 (including being 3 less because of peer-id) and the tun device is 1447. (Not sure why tun-mtu and tun device mtu are different by 72.)

If I then perform an outgoing UDP benchmark with UDP packet size 1419 (28 less than the tun mtu of 1447, due to 20 IP bytes and 8 UDP bytes) and look at wireshark, I see only 1500 byte packets being transmitted out to the internet, at least during the large transmission. Seems clean.

If I use their configuration and allow a UDP packet size 1472 (28 less than tun mtu of 1500) and look at wireshark, I see fragmented outgoing packets, alternating between 1500 and 85 bytes.

Using my configuration, my outgoing UDP benchmark increases by 48%, and becomes much more consistent.

Unfortunately, even using my configuration, their server has its own configured mtu value, so I have no way to increase my incoming bandwidth, unless I convince them to change their server configuration.

Which doesn't seem likely to happen, since it looks like everyone's doing it the way that seems backwards to me.