It may be way simpler for basic setups but it quickly becomes as or more complex than ipsec for more advanced setups such as those involving dynamic routing and/or fail over routes. The additional complexity is due to the fallout of allowed-ips and how they are used.
What you essentially end up with is that a wireguard interface represents a point to multipoint non-broadcast network. Any one that has dealt with Frame Relay or ATM can tell you what a headache dealing with dynamic routing over such a network can be. Fun things like having to hand configure your OSPF neighbors. This can be overcome by configuring each Wireguard peer to a separate interface essentially making the interface a point to point network or using another tunneling protocol overtop of Wireguard such as GRE or L2TP. But you quickly lose any simplicity advantage.
Even for something like a static floating route for backup Wireguard can be more complex because a Wireguard interface once turned up will not show as down unless manually turned down. This means the connection has to be monitored and the backup route installed based upon the monitoring criteria. Again nothing that can't be overcome but doing so raises the complexity.
Unless you are assigning each peer to a different Wireguard interface and setting allowed-ips to all ips you also have to figure out how to update the allowed-ips for peers to be updated as the routing changes.
Personally I would have preferred if allowed-ips didn't exist and each peer was assigned to a sub-interface whose status could change based upon keepalives. Then the normal ip routing and filtering facilities of the kernel could have been used instead of the current situation where you have some amount of filtering and routing effectively being done by the Wireguard interface and then some being handled by the kernel.
I used to contribute quite a bit to the Wireguard package for Ubiquity routers but stopped when I switched to ipsec. It was apparent that Wireguard was more complex to setup and troubleshoot for even slightly advanced scenarios.
As for your statement that it is faster that greatly depends upon the platform being used. It is faster than OpenVPN almost everywhere but many network devices have SoCs that provide slow CPUs and acceleration for ipsec or at least the crypto underlaying it. On those platforms it often is not faster than ipsec.
Don't get me wrong despite my comments overall I think Wireguard is pretty darn nifty and am happy to see it included in the kernel. I just think it needs more tooling developed around it before it can be a less complex replacement for ipsec in even some fairly basic scenarios.
This doesn't even cover the enterprise road warrior VPN scenarios where Wireguard currently lacks many of the more advanced enterprise features of OpenVPN or proprietary offerings from the likes of Cisco, Pulse Secure or Citrix. Hopefully development of the additional protocols and tools needed to add support for more advanced scenarios is accelerated now that Wireguard will be in the kernel. Of course once these are added there is the risk that a Wireguard based feature comparative implementation ends up just as bloated and complex to audit as any of the current alternatives.