Sorry, it was late last night, so I did not write a longer response. Let me add some more clarification 
These two points are not important. As you can see, once a successful handshake has been performed, WG on RouterOS will remember the remote address and port of the remote peer in current-endpoint-address and current-endpoint-port. These are the values that will be used when WG sends out UDP packets. This is how WG can easily support roaming. A mobile peer can roam between LTE/5G and multiple WiFi networks for example, while still maintaining an active WG connection. The other side just needs to remember the latest address and port of the handshake, and they don't need to match the initial values you specified in endpoint-address and endpoint-port.
This roaming applies to both sides. WireGuard have equal peers on both sides, not a client and server concept. By default, when one side has something to send, that side can always initiate a connection (start a handshake if there was no recent enough handshake, usually more than a couple of minutes), as long as it has the address and port information of the other side (what in current-endpoint-address and current-endpoint-port, or if those don't have value yet, then what in endpoint-address and endpoint-port).
So when you turn off the WG tunnel on the phones or laptops, at that moment, there might still be on going connections that was going through the tunnel. When there are still packets of those connections on the MikroTik router side, WireGuard on RouterOS will try to send them to your phones or laptops. When the handshake timeout (a couple of minutes) has not elapsed, it will send the UDP wrapper packets, which will not arrive. Then it will try to establish a new handshake, by using the latest known data from current-endpoint-address and current-endpoint-port. That will get no response, and the handshake will fail, and is the reason for the log messages you saw. After a few handshake attempts, WG on RouterOS will give up.
Again, this is how WireGuard was designed. There is no side that only listens for "incoming connections" and acts as server, both peers are similar.
MikroTik to work-around the issue with the log message, has introduced the "Responder" setting to the peers in 7.15:
with some more fixes in 7.17:
When you now turn on the option, even when there are still packets in the queue that need to be send to the other side of the tunnel, RouterOS will not try to initiate a new handshake anymore. It will only listen to handshakes initiated by the other side, similar to a "server". But this is not a standard WG behavior, only a special workaround from MikroTik.