Load balancing is more effective using all available bandwidth and easier/less complex & straightforward on RouterOS — that’s why I pitch it 
… But your right failover is going to be noticeable since it’s connection-based. And “hitless failure” and magic bonding is what Peplink pitches. I get the latter pitch sounds better, but lot of complexity over potentially telling folks to “refresh your browser” when WAN failure are hopefully very rare…
So if need it’s more “hitless failover”, /interface/bonding is still what you need. And since, on Mikrotik, it needs an ethernet-link interface… EoIP is the way to meet the bonding interface’s requirement. It’s entirely possible WG might be better, than IPSec in this case, IDK… Since you’re the expert on WG, that seems like a fine approach to combine with EoIP and bonding. On older routers, IPSec is likely to be offload (where WG might not be), but on anything modern/powerful, I’m not sure IPSec vs WG matters too much here.
Also…If the traffic is truly internet traffic, you technically only need 2 x EoIP without any “VPN”, but still /interface/bonding interface. Now without any VPN, GRE does need both sides having a public IP. So using WG does add BOTH dealing with only one side (i.e. CHR) having a public IP, as well is adding another layer of encryption too. But if bond is ONLY internet bound traffic, and would have already been “exposed” directly leaving the a “local” WAN to internet… So adding encryption on the one hop to CHR, may not offer anything, but overhead… Peplink support running its tunnels without encryption to save on the overhead.
One more detail, if “super reliable” is need. You can just duplicate all packets over BOTH WANs on Mikroitk using a different mode in /interface/bonding. i.e. “broadcast”, which be even more “hitless failover”.
It when you have an office full of people, generally reliable internet (that does not often fail)… you just don’t get a lot of out. But if your use case is you have some critical traffic where if the connection drops, it a real problem… then yeah bonding is useful. But you can see from the length of these posts - that just gloss over details - it’s not as simple…
Last tip… Just don’t ignore /queue/tree with /interface/bonding. Things like Peplink to do some QoS/queuing internally, but there are using same Linux queue things as RouterOS can (just with queue parameters pre-determined by Peplink UI setting). But… typically there not very complex, but do prevent single WAN from saturation, which is even important to do with bonding. But you do not have create queues for everything/all traffic a la @pcunite’s older QoS guide (although you could) — just setting up each WAN’s max-limit= to the actual minimum speed of the line really help here to avoid bufferbloat/other related issues. /interface/bonding will only make things like bufferboat worse… so just an upload traffic would help with any use of EoIP+bonding. I’d get it working first, but “playing” with some queue’ing things do similar “WAN smoothing” as Peplink.