I would agree with your suspicion that ChannelFly may result in sudden wifi disconnection for clients that do not cope well with Channel Switch Announcements.
I would actually recommend using ChannelFly in "run-stop" mode in this case. In the AP Group Settings, you can check an option for "Turn off ChannelFly after ____ minutes of uptime". This will cause AP's to use ChannelFly to pick a channel, then shut off ChannelFly. Typical values are 60 minutes or 120 minutes. So, for the first hour/two after you reboot an AP, it will hop around and find a good channel, then stay there for the rest of the uptime. If a client complains about interference / poor performance on an AP, you can reboot it from the ZD to cause it to pick a different channel.
Another improvement on this that works really well for me is I've got two AP Groups, one called "ChannelFly" and one called "No ChannelFly". The only difference is "No Channelfly" has the run-stop option picked. So, once in a while during a low usage period, I move all the AP's to the ChannelFly group to have them pick some different channels, then I move them back to the "No Channelfly" group.
If you are manually assigning channels, you should definitely NOT assign the same channel to every AP. You should pick different channels on each AP, and channels without much interference. Of course, this is much easier said than done, which is exactly what Ruckus came up with ChannelFly technology.
Some people say you can also use Background Scanning instead of ChannelFly, but personally, I've found that Background Scanning also jumps around a bit, and is not as good as run-stop ChannelFly.
Also, do you have SmartRoam configured by any chance?