From my own experience, there are no caveats in disabling the filters.
To be honest, if there were an alarming amount of probe data coming from unknown/unassociated SSIDs, I'd be more concerned about the rogue SSIDs popping up in the vicinity of your WLAN, and the interference they would cause, as a posed to the increase in probe data.
It will definitely increase accuracy on location, but don't expect it to magically turn a low density location deployment into a <5 meter accurate one. (although, I don't know the physics behind this yet, or the actual gains from doing this) If you're particularly worried, just keep an eye on the bandwidth of the tunnels going back to the controller. (unless you have a 3850 already)
If your APs are just bridging clients from the wireless right onto your wired network, then you're going to see this from time to time. Clients will appear from different ports as they re-associate to other APs/cells in the ESSID.
I'm presuming you're talking about Cisco IOS here, based on the term "MACFLAP", which appears in their log messages when this happens.
For example: "%SW_MATM-4-MACFLAP_NOTIF: Host 0011.2233.4455 in vlan 123 is flapping between port Gi1/1 and port Gi1/2"
What this means is that the switch is having to "re-learn" an Ethernet MAC address out of a different port than what is cached in the hardware forwarding table. This takes a little CPU time for each event, and having it happen more than couple times in a row will cause that MACFLAP message to get logged as more and more CPU time is consumed.
However, this should not cause the entire table to be flushed or cleared. Just the entries for the flapping source MAC address should be getting affected.
Now, in your case, if this is an infrequent message and it's just wireless clients moving from place to place, I wouldn't worry about this too much.
To prevent this, some centralized wireless client termination would be needed. This way, frames would pop out onto the wired VLAN in a consistent place.
However, if this is happening frequently for many MAC addresses, it could be indicative of a Layer 2 loop which will definitely need some investigation. :p
Best Answer
Your are correct about 802.11r and it's issues with lack of client-support.
Assuming your deploying WPA2-Enterprise or similar (where session keys are established)...you should take a look at the following. It's great reading, especially since your inquiring about 'best practices' with very little detail on your deployment (ie target devices/applications...VoWiFi?):
802.11r/k: http://www.revolutionwifi.net/2013/05/apple-ios-fast-roaming-with-aerohive-wi.html
CCKM/PCK-OKC and description of roaming techniques: http://www.revolutionwifi.net/2012/02/wi-fi-roaming-analysis-part-2-roaming.html
Follow the links at the bottom of the 2nd URL for Cisco recommendations, but again...will depend heavily on your target device/application.