SACK was added later, so there is a need for backward compatibility, both for end hosts and for middleboxes (also see below). The
SACK-permitted option fulfills just that.
SACK-permitted is sent from A to B to indicate that A is willing to receive SACK options. For SACK handling (as for most retransmission handling), TCP can be thought of as consisting of two simplex connections with different state each. So it is perfectly legal (but uncommon) to have SACK traveling only in one direction (the reverse direction of the
SACK-permitted during SYN or SYNACK).
Normally, you may want to leave SACK enabled, as it improves performance. However, there were (and maybe still are) firewalls and NAT boxes out there that change the SEQ and ACK header fields but are unaware of SACK and thus do not correspondingly adapt the sequence numbers in SACK options. This can lead to connections hanging (as SACK has acknowledged a different segment which has not been received). This is the reason you may want to disable SACK even if both machines do support it.
SACK can be disabled (for testing or with the abovementioned ugly middleboxes present) on *BSD systems (including MacOS X) by entering
sysctl -w net.inet.tcp.sack=0 and reenabled by setting it back to 1. On Linux,
sysctl -w net.ipv4.tcp_sack=0 achieves the same effect.
The first paragraph of section 4 in RFC 2018 allows SACK to be sent when SACK-permitted has been received. Normally, a SACK-capable host will announce SACK-permitted. I cannot imagine a useful scenario where a SACK-capable host will not advertise SACK-permitted, but will use SACK (an unrealistic example would be a middlebox badly fiddling with SACKs in one direction only). Therefore, I do not expect SACK used in one direction only.
A quick test with Wireshark against Linux, MacOSX (probably generalizable to *BSD) and an HP printer shows that they will respond with SACK-permitted in the SYNACK exactly when SACK-permitted was in the SYN. However, I see nothing in the RFC that would require or encourage this behaviour.