Set B, in isolation does not allow ssh communications. It merely permits a connection allowed by other rules to be continued or (subject to certain combinations such as for H.323 and FTP) for new connections to be established between IP addresses which have an existing entry in the conntrack table.
The problem with Set A is that it is not stateful - an attacker could create a client connection to any port on your server as long as the client end used port 22. To address this problem you need a stateful firewall - i.e. one that takes into consideration the direction of the connection. Hence its more common to see something like:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
Putting ESTABLISHED,RELATED first means that the whole ruleset need only be parsed once per connection - subsequent packets are matched by the first 2 rules. This can have a lot of impact on a latency with a complex ruleset.
The downside of using stateful firealling is that it consumes resource on the server - when the conntrack table fills up, the firewall will start dropping connections. OTOH, the stateful module allows for more complex demand management - typically by limiting the rate of connections.
Really? While there are versions of ssh using certificates for managing keys it is a very unusual case. Do you mean key pairs?
None of both sets is superior in general
Which of both sets is more restrictive
If neither is superior, how can one be better?
For a host firewall, you should use stateful firewalling - to prevent the bypass described earlier.