OK - so there's an old saying I learned when I started doing networking: LAN's are bridged and WAN's are routed.
What this means is that networks that host lots of end stations are going to be well-served by physically proximate switches with effectively infinite, cheap, and readily available bandwidth. Lots of broadcasts and multicasts to find services? No biggie. Random bursty transfers? It's all localized, so who cares. Someone blew something up and the LAN is fried? Painful but it's only effecting people within that site and within that network. In larger enterprises this tends to mean a few dozen to a few hundred people in part of the floor of an office building. If something breaks it's a critical problem but in such situations the workers can often just take the elevator to another floor while someone fixes the problem.
The problem with what you're describing (old-style bridging) is that it exactly fails at all of the above. A problem that saturates a given LAN now also saturates your most limited resource: inter-site bandwidth. That saturation means that an entire site is now potentially offline. The cause of such an issue could be a bad NIC, misbehaving app, a user who decided to run a huge backup job in the middle of the day, a misconfiguration of that STP you've been running for years. Heck, something as innocuous as an end user in a conference room accidentally plugging in two ports from the wall into a single dumb switch can cause a loop that ends up taking down both of your wireless links (and thus all communications) while someone tries to find a laptop and console cable to attempt to isolate the problem - assuming, of course, they're in the right site to help.
Seriously - everything is going to run better if you run L3 over those links. You have the potential to implement traffic shaping / QoS in an intelligent way to prioritize your voice traffic before it hits the radio, you can actually engineer some traffic to normally use the backup link while sending the remainder over the primary. As Ron correctly points out, failover is measured in milliseconds rather than minutes. Want to add a third site? Easy. Try that with STP and it starts to get ugly. Add a third link? Maybe come up with a solution where you put an Internet connection in the second site and use a site-to-site VPN to carry certain traffic? No problem.
The thing is that while - ideally - each site ends up with its own subnets (the model shown to scale and function reliably and the recommendation of literally every significant network vendor on the market) you could add in some kind of overlay to map L2 over the safe/sane L3 backbone. Set up L2TP or OTV via some routers and have the subnets show up wherever you want. Heck, consider some of the possibilities with VXLAN-EVPN where a modern switch can make sure any subnet shows up anywhere while still locally routing traffic over that L3 backbone.
Relying on spanning tree across remote sites for redundancy is a bad idea even with two sites. It was bad in 1995 and it's no better in 2017. It gets progressively more horrible as any amount of size or complexity is added. Seriously - to this day I still periodically see horrific STP problems in major data centers operated by highly qualified dedicated crews under fairly controlled conditions. Moving this into the realm of potentially flaky long-haul wireless and workgroup-scale hardware isn't going to improve things.
