What's the advantage of sending an RST packet after getting a response in a SYN scan?

Leaving a connection in syn_rcvd state will raise flags as well as this is a common denial of service attack.

If you don't send a RST, the server will remain in a syn_rcv state for up to 60 seconds and retransmit the SYN ACK up to 5x. This will waste resources on the network you're scanning and cause a bunch of (depending on the speed and success of your scan) of retransmitted SYN ACKs being sent back to you.

The 60 second and 5 retries are linux defaults - these values will vary.

This is technically false: Nmap does not send a RST at any point in the half-open SYN scan. Instead, it relies on the scanning machine's OS to send RST packets in response to what the kernel views as unsolicited SYN-ACK packets. This is the same mechanism that is probed by Nmap's ACK scan (-sA) to map out firewall rules. Of course, this means that if your scanning system has a firewall, it's very likely that it drops unsolicited SYN-ACK packets instead of responding with RST, so you could potentially create a SYN flood condition. It's best to turn off such rules or to add an explicit rule to allow sending of RSTs in this case when performing large scans so that you don't burden your targets.

Regarding stealth, it's important to know your history. Nmap was released in 1997, predating BlackICE, Snort, and Bro (all created in 1998). At the time the "stealth SYN scan" was so named, an Intrusion Detection System was a program to check your logs for failed connection attempts. Since SYN scan never completes a TCP handshake, the application is never notified. The event dies in the kernel and there's nothing in the application log to indicate anything went wrong. These days, however, the situation is almost inverted; organizations are much more likely to have a network IDS/IPS than a properly configured SIEM/UTM/log analysis capability.