MAY-13 is according to Appendix B "Send ACK for out-of-order segment". Out-of-order segment is the segment that is NOT the next expected segment, i.e., the one that is not RCV.NXT. This happens when the next expected segment is lost, or the segments are reordered for some reason.
The ACK mechanism in TCP is as follows: TCP always sends the next expected sequence number in ACK. When new in-order segment arrives, the receiver updates RCV.NXT and sends ACK. When out of order segment arrives, the receiver sends an ACK for RCV.NXT, which is a duplicate ACK (another ACK with this value is already sent). The sender notes how many duplicate ACKs have arrived. After receiving 3 (or dupack threshold) duplicate ACKs, sender assumes that the segment is lost and acts accordingly.
The word MAY refers to - it is up to the implementation on whether to actually implement it or not. Technically, TCP should work correctly if duplicate ACKs are not sent: retransmissions will be eventually triggered by retransmission timer. The performance however will be reduced significantly, so I would assume that most implementations do send these ACKs.
Also, loss recovery is a pretty complex topic in TCP. There are quite a number of other RFCs that specify how loss recovery is done. This includes for example selective acknowledgements (SACKs), which, in addition to sending ACK for RCV.NXT also send a TCP option listing what segments are missing. See Sec 3.3 of RFC7414 for a list.
TCP has a mechanism, called delayed acknowledgements. In order to reduce the number of ACKs sent, when TCP receives in-order segments, it does not acknowledge every one of them. The standard recommendation is to acknowledge every other in-order received segment, and ensure that the ACK is not delayer by more than half a second. Since TCP is window-based and uses cumulative ACKs, this is not a problem. The mechanism is explained in Sec 184.108.40.206.