Change:
In order to quickly complete the handshake and avoid spurious retransmissions due to crypto retransmission timeouts, crypto packets SHOULD use a very short ack delay, such as the local timer <del> granularity.  ACK frames MAY be sent immediately when the crypto </del> <ins> granularity.  ACK frames SHOULD be sent immediately when the crypto </ins> stack indicates all data for that packet number space has been received.

Discussion:
Changes MAY to SHOULD.
Note that stacks generally don't indicate that all data is available, they just provide newer keys, or provide data that should be protected with those newer keys. But the spirit of this is fine.
On receiving the INITIAL packet, the server passes the CRYPTO data to TLS which then does a bunch of things like computing handshake key, generate INITIAL data etc and then passes it to QUIC. From measurements, it takes ~10ms before the server sends out the INITIAL packet and ACK for client's INITIAL packet. Now, the first RTT measurement doesn't include ack delay. For a very low RTT connection (two machines connected back to back via ethernet), this causes the initial RTT ~ 10ms, which is too high for such a connection. Even after subsequent RTT samples of 0ms, would take a long time to normalize the high initial value. Is there a reason why we don't subtract ack_delay from measured RTT for the INITIAL packet?
The reason to not subtract ack_delay on the first ACK is it could allow the peer to manipulate the SRTT, which may be particularly dangerous at the beginning of a connection. As a mitigation, the current text in 4.1 of Recovery says: "In order to quickly complete the handshake and avoid spurious retransmissions due to crypto retransmission timeouts, crypto packets SHOULD use a very short ack delay, such as the local timer granularity. ACK frames MAY be sent immediately when the crypto stack indicates all data for that packet number space has been received." URL We could add some text indicating that sending an ACK immediately improves the first RTT sample if that seems helpful?
PR is a substantial rewrite of the RTT estimation section, so it may be worth reading that to see if it provides the rationale you were looking for.
This is an interesting point. In addition to having an inflated RTT, there's also the risk of the crypto timer firing for long RTTs. In quicly, we don't delay acks during the handshake to avoid these issues. I wonder if this is worth mentioning in the draft.
NAME we already have :
That "MAY" is odd. You can always ACK immediately. Whether or not you "SHOULD" varies, but in this case maybe we SHOULD RECOMMEND an immediate ACK rather than having it be OPTIONAL.

I believe the MAY is only possible if the crypto stack provides a clear signal that it's received all crypto data in Initial or Handshake packets? I wasn't sure how likely that was to be available, which is why it's a MAY, but I'm also happy to make it a SHOULD. The text used to say you should always ACK crypto packets immediately, but a client might want to wait a short period of time and ACK the servers Initial in a coalesced packet with the client's Handshake ACK/CFIN, so it was adjusted to " a very short ack delay, such as the local timer granularity".
Agrees to what NAME says. "SHOULD if the crypto stack provides such signal" is what I'd favor to see in the text, I think the current text implies that.
NAME : indeed, thanks for pointing me to the text. I'm in agreement as well on turning the MAY into a SHOULD. I'll send a PR.
Sending an ACK immediately for client's INITIAL might be helpful in estimating RTT correctly but it has the disadvantage of not being able to coalesce the ACK with server's INITIAL CRYPTO. Some implementations might even coalesce the Handshake packet.
NAME : that is already covered by the current text.