Did you get those quotes from a man page, or from the script you are looking into?
From personal experience, if I set my default policy of DROP, and I have a rule that explicitly ALLOWs a packet, it passes through fine.
In the example you posted, the RETURN rule will never match if iptables is behaving properly. When you ACCEPT a packet, it moves on through routing and will never match another rule. Think of the following example:
iptables -P INPUT DROP
iptables -A INPUT -p tcp --dport 80 -j SOMEOTHERCHAIN
iptables -A INPUT -p tcp --dport 80 -j SOMEOTHERCHAIN2
iptables -A SOMEOTHERCHAIN -p tcp --dport 80 -s 192.168.0.0/16 -j ACCEPT
iptables -A SOMEOTHERCHAIN -p tcp --dport 80 -s 10.10.0.0/16 -j ACCEPT
iptables -A SOMEOTHERCHAIN -p tcp --dport 80 -j RETURN
iptables -A SOMEOTHERCHAIN2 -p tcp --dport 80 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A SOMEOTHERCHAIN2 -p tcp --dport 80 -j RETURN
Any packet destined for port 80 moves into SOMEOTHERCHAIN, if it's source is 192.168.0.0/16 or 10.10.0.0/16 they are allowed through the firewall, all others will RETURN to the originating chain(in this case the INPUT chain) and then branch to the SOMEOTHERCHAIN2 rules(which will probably never match, nothing coming into the INPUT on port 80 will be established or related thanks to process forking).
Now, the RETURN statement is redundant, if it doesn't match the two rules for ACCEPT it will automatically fall back to the INPUT chain which would move it along in it's processing order.
Now, why wouldn't I just add my state checking in my original table? Sometimes it's for readability or script processing.
iptables -nvL --line-numbers INPUT
iptables -nvL --line-numbers SOMEOTHERCHAIN
iptables -nvL --line-numbers SOMEOTHERCHAIN2
Would give me the statistics per table that I can then use perl or python or bash to grep through and get numbers.