why not kill the connection
The question about ACKs has the following textbook answer:
IP is an unreliable network layer. Among others packets can be delayed by a large amount (at least in theory, AFAIK that also happened in practice when TCP was designed). Thus TCP should be able to handle receiving wrong packets, in particular packets from previous connections that are arbitrary delayed.
Thus, when TCP receives a segment for the same socket, which however has wrong sequence number, it cannot distinguish between the client making a mistake and a network delivering outdated packet. Thus it would be a mistake to kill the new connection on possibly outdated packet. TCP also has random sequence numbers precisely for this situation. New connection should choose initial sequence numbers so that outdated packets will not fit in receiver window with "very high probability". This could happen though...
So, no, TCP does not expect the other peer to recover. Instead, if this was indeed a mistake of the other peer, the other peer receives a RST, which kills the connection on that peer's side. It just cannot know if the other peer indeed did a mistake or something wrong happened in the network.
I am not sure about security, since I never new about it but I think the same logic applies
Why not Re-transmitting SYNACK
It kinda looks like, retransmitting SYNACK actually happens. However it happens on a timer, not on a wrong segment, i believe, for reasons described above.
There is a trace with retransmitted synacks here and here.
A note about killing SYN-RECEIVED
Killing a TCP connection involves mostly deallocating memory for connection state (the TCP control block or TCB in the rfc). If you read through the specification, you may notice that it specifies allocation and de-allocation of connection state mostly as result of user action, not result of incoming packets (deleting TCB on transition to close is specified as well, but it is more to ensure that the opposite does not happen). This should tell you, that it is implementation detail on how to handle deallocating connection state for sockets in SYN-RECEIVED state.
In practice, it is advisable to only allocate small number of strictly necessary state for SYN-RECEIVED, and only allocate whole TCP control block when the ACK from the peer (third handshake message) is received. This is done to protect against so called Syn-Flood Attack. You can read about it here.