OpenWrt doesn't have any active band-steering at this moment, leaving roaming decisions purely to the connecting clients. Some clients tend to be rather 'sticky', once they've made a connection and won't roam to a stronger BSSID if they get (back-) in range.
In contrast some commercial 'mesh' APs employ active bandsteering to 'help' clients making good choices (this means actively deauthing a client, if a dæmon on the AP deems the connection to be better served by the other band or a nearby AP). While this helps sticky clients, it comes with some issues of its own (connection/ interoperability issues with some other clients).
While hostapd has gained some very basic bandsteering capabilities (far less sophisticated than that of commercial offerings) recently (for better or worse, which is indeed debatable), this only works if both radios are served by the same hostapd instance (as you see, here bandsteering doesn't cross multiple APs). OpenWrt however currently creates dedicated hostapd instances per radio, which prevents the two instances from communicating the best bandsteering solution with each other. There are ongoing efforts to change this, but that's not final yet (and won't cross between multiple APs either).
Setting up IEEE 802.11r (and optionally IEEE 802.11k and IEEE 802.11v) are other options to help the connected clients to make better roaming decisions, but this leaves the actual decision to the clients (and only helps very recent/ highend clients).
In recent times I've observed android clients to be reasonably smart in their roaming decisions, but that doesn't necessarily apply to every OS/ device.