The last-handshake column as mentioned above is completely absent if no successful handshake took place yet. If the column is present but the time shown is longer than 2 minutes, it is also suspicious.
There is a moment in your exports that I don’t understand. You wrote that only one of the Tiks had a public IP, but in both exports the address attached to ether1 is the same, 192.167.1.3, and the addresses of the gateways of the default routes are also identical, 192.167.1.1.
Since 192.167/16 is a public prefix assigned to an Italian ISP, should I understand that as a confusing way of obfuscation of thе actual public address, or is this an address range Telkom uses as the default LAN subnet on their CPEs and when you say that one of the Mikrotiks has a public address, you actually have in mind that the public IP is on the WAN of the Telkom’s CPE and there is a port forwarding rule or DMZ configured on the CPE towards the WAN address of the Mikrotik? BTW you forgot to obfuscate the public address of site A in the export from site b…
Other than that, you are apparently missing one important moment regarding how Wireguard is implemented, and the examples in the manual are unfortunately not very helpful as they do not explain things that are obvious to seasoned network engineers who write the manuals but far from obvious to first time users.
Each Wireguard instance (represented by the “interface” object) that runs on a router behaves as an independent virtual router with its own routing table. Unlike IPsec that overrides the results of the common routing, the Wireguard instance only handles traffic that the “big” router explicitly sends to it, and uses the allowed-address lists configured for the individual peers to choose the proper destination peer for each packet. So the fact that you have configured allowed-address=192.168.80.0/24 for the single Wireguard peer on site b had no impact on the “big” router - you have to add a route dst-address=192.168.80.0/24 gateway=wg_Telkom. This is a different experience than on the prototype implementation of Wireguard on Linux where the startup scripts bundled to the installation package take care of this - they copy the destinations linked to the peers in the Wireguard configuration into the routing table of the machine.
Of course you have to do the same on Site A. On the other hand, attaching address 10.0.0.2/24 to interface wg_Telkom creates a route dst-address=10.0.0.0/24 gateway=wg_Telkom dynamically, but as none of the peers has allowed-address=10.0.0.x/y, the “big” router will send packets for 10.0.0.x to the Wireguard instance but the Wireguard instance will drop them.
Lastly, Wireguard uses a “stealth” behavior so it does not attempt to establish a session until there is a payload justifying that, or unless a keepalive is activated. Since site b is (apparently) behind a NAT, a packet for 192.168.90.x from Site A would never be sent as Site A does not know the public address and port of site b, so the first packet causing the session to establish after a long pause would always have to be sent from site b to 192.168.80.x; this is not practical, so you have to add persistent-keepalive=30s to the configuration of the peer at site b.
So I’d suggest you implement the changes above, and if it still does not work, post the exports again so that we could look what else is missing.
Also, if the router at Site A has the public IP on itself (or if all traffic from the public IP is forwarded to it), the absence of any firewall rules on it means that the only thing that prevents it from becoming a zombie in a botnet is a strong password.