This means if these channels detect they've been shunned (kicked out of the group) they won't automatically disconnect() themselves and then connect() themselves to rejoin the group. Is this intentional?
Brian.. in what situation they can be kicked out?
The failure detection protocol on another node considers the node to have failed  and the VERIFY_SUSPECT protocol on the coordinator node concurs . The coordinator then publishes a new view that doesn't contain the suspect node. But the node hasn't entirely failed; it begins working again and tries to send messages to the group, of which it is no longer a member.
Typically this would be a case of something happening on the node that prevents it responding to FD heartbeat requests for a period. Maybe a 100% CPU situation or something blocking all the threads that pass messages up from the transport protocol. (In JG 2.4 there is just one such thread, so if it gets blocked for a while in the app, the node can be suspected.)
 Details on the most common failure detection protocols:
Some more comments on this:
The current default for for JG 2.6.3 and the proposed default for JG 2.4.3 is auto_reconnect=true and auto_getstate=false.
If you have channel that uses state transfer and accepts those defaults, if the channel gets shunned and reconnects, a state transfer will not happen after the reconnect. As a result, the app's state on that node will be out of sync with the rest of the cluster. Probably not a good thing.
Recommend JBM never just accept the defaults. Always specifically configure what you want via channel.setOpt(...). If you guys are doing a CP release for EAP 4.3 CP01 and can add that in, then you are set no matter what the defaults are in a particular JGroups release.