... not really. The script makes use of a function called "del_client" (more appropriately termed the "del_client" method in hostapd) to disconnect clients. This method of disconnecting a client will leave the client scrambling to find another AP to attach to. No Fast Transition or 802.11r will take place in this scenario.
I believe this "del_client" method is also used by the disconnect button you see on the Luci's Status -> Overview page (scroll down until you see the red "Disconnect" buttons). If you go ahead and try it for yourself by disconnecting your Apple device there, it will still quickly connect to another AP (if within range), and in fact it will seem like the transition is seamless as indicated by your phone's wifi indicator never disappearing. But no 802.11r doesn't kick in. It is a slow transition not a fast transition.
It is actually easy to tell if it is 802.11r FT or not for each transition that takes place. Type 'logread' on an SSH terminal session to the router right after a device has been transitioned to that router. If you see
Thu Nov 25 01:08:07 2021 daemon.err hostapd: nl80211: kernel reports: key addition failed
Thu Nov 25 01:08:07 2021 daemon.info hostapd: wlan0-1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 10)
Thu Nov 25 01:08:07 2021 daemon.notice hostapd: wlan0-1: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx
getting displayed, with xx:xx:xx:xx:xx:xx being the MAC address of your client device, then FT / 802.11r was used to do the quick transition (a ~20ms switch according to some other forum posts).
If you see this instead
Thu Nov 25 01:06:38 2021 daemon.info hostapd: wlan0-1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
Thu Nov 25 01:06:38 2021 daemon.info hostapd: wlan0-1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 1)
Thu Nov 25 01:06:39 2021 daemon.notice hostapd: wlan0-1: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx
Thu Nov 25 01:06:39 2021 daemon.info hostapd: wlan0-1: STA xx:xx:xx:xx:xx:xx RADIUS: starting accounting session 8F14899AA89FD72E
Thu Nov 25 01:06:39 2021 daemon.info hostapd: wlan0-1: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Thu Nov 25 01:06:39 2021 daemon.notice hostapd: EAPOL-4WAY-HS-COMPLETED xx:xx:xx:xx:xx:xx
Then no, FT / 802.11r was not involved in the transition.... a slow transition if you will (~200ms according to that same post I have read somewhere).
Just for the sake of knowledge sharing, some of the transition management tools like Dawn instead use a function called "wnm_disassoc_imminent" (more appropriately termed the "wnm_disassoc_imminent" method in hostapd) to reassign clients to other APs. With this method, 802.11r will for sure be taking part in the transition process. As this method allows for all relevant information to be sent to the client regarding the transition --> from which source AP to which destination AP. The script on the other hand simply cannot use "wnm_disassoc_imminent" so it is stuck with "del_client", as it as no knowledge of any other AP in the local network.
Edit: I should point out one more thing too - you mentioned about using the 'blacklist' option provided by the script to block those already working devices like Apple devices.... Essentially what this does is equivalent to telling the script "leave my Apple devices alone, do not touch them at all, do not issue "del_client" commands to them". So your Apple devices will continue to make their own roaming decisions like they always have, and yes these self-initiated roaming actions will make use of 802.11r.
Edit 2: It actually might be a good idea for you to implement the script for your Android devices. Add your Apple devices to the blacklist so they continue to make their own 802.11r roaming decisions as you say they are roaming well with 802.11r enabled in your network. The script will (from experience) certainly encourage your Android devices to roam more aggressively, albeit doing "slow transitions" (but still zero interruption most of the time). With that said, I have faith that once Dawn stabilizes and bugs are ironed out, it will be a once-and-for-all solution of managed roaming with FT for all of your devices that support 802.11 r/k/v, which pretty much covers all modern Apple and Android devices.