Change:
Also removes obsolete text about acknowledging CRYPTO frames quickly, now that Initial and Handshake packet spaces have a maxackdelay of 0.
Sorry I'm late here but I think it would still be good to mention that congestion control usually is supposed to work on a RTT granularity and if you send less ACKs than one per RTT that can have an impact on cc. I don't think this has to be a normative requirement given you have normative requirements on maxackdelay and a reasonable default value but it would still be good to mention this dependency as cc is done on sender and ACKing on receiver and therefore it might not always that obvious.
The spec gives no reason (that I can see) as to why an ACK frame must be sent at least once per round trip (assuming there are ack-eliciting packets to acknowledge), effectively overwriting the ACK delay logic when the RTT is very small. If the RTT is smaller than the platform's timer granularity, this isn't really even possible. I propose to remove this requirement. If the WG instead feels that we should keep this requirement, then there should be a reasoning for it; and probably an update to the PTO calculation as well.
As I commented on the PR that this came up in, given we have an explicit maxackdelay that's now communicated, removing the 1 ACK per RTT requirement seems wise. TCP has no such recommendation and I'm unaware of any indications or proposals that it should have such a property.
NAME point that the RTT can be smaller than the platform's granularity is a good one. I agree that this text ought to be removed.
This is changing text in a SHOULD statement, so I believe it should be marked as design.
LGTM

Discussion:
eliciting packet.  This recommendation is in keeping with standard practice for TCP RFC5681. <del> A receiver's delayed acknowledgment timer SHOULD NOT exceed the current RTT estimate or the value it indicates in the "max_ack_delay" transport parameter.  This ensures an acknowledgment is sent at least once per RTT when packets needing acknowledgement are received.  The sender can use the receiver's "max_ack_delay" value in determining timeouts for timer-based retransmission. </del> <ins> An endpoint MUST NOT excessively delay acknowledgements of ack- eliciting packets.  An endpoint commits to a maximum delay using the max_ack_delay transport parameter; see transport-parameter- definitions.  max_ack_delay declares an explicit contract: an endpoint promises to never delay acknowledgments of an ack-eliciting packet by more than the indicated value.  If it does, any excess accrues to the RTT estimate and could result in delayed retransmissions from the peer.  For Initial and Handshake packets, a max_ack_delay of 0 is used.  The sender uses the receiver's "max_ack_delay" value in determining timeouts for timer-based retransmission, as detailed in Section 5.2.1 of QUIC-RECOVERY. </ins> In order to assist loss detection at the sender, an endpoint SHOULD send an ACK frame immediately on receiving an ack-eliciting packet

determine whether an immediate or delayed acknowledgement should be generated after processing incoming packets. <del> Acknowledgements of packets carrying CRYPTO frames SHOULD be minimally delayed, to complete the handshake with minimal latency. Delaying them by a small amount, such as the local timer granularity, allows the endpoint to bundle any data sent in response with the ACK frame.  ACK frames SHOULD be sent immediately when the crypto stack indicates all data for that packet number space has been received. </del> Packets containing PADDING frames are considered to be in flight for congestion control purposes QUIC-RECOVERY.  Sending only PADDING frames might cause the sender to become limited by the congestion

processed.  An endpoint MUST NOT include delays that is does not control when populating the Ack Delay field in an ACK frame. <del> An endpoint MUST NOT excessively delay acknowledgements of ack- eliciting packets.  An endpoint commits to a maximum delay using the max_ack_delay transport parameter; see transport-parameter- definitions.  max_ack_delay declares an explicit contract: an endpoint promises to never delay acknowledgments of an ack-eliciting packet by more than the indicated value.  If it does, any excess accrues to the RTT estimate and could result in delayed retransmissions from the peer.  For Initial and Handshake packets, a max_ack_delay of 0 is used. </del> 13.2.6. ACK frames MUST only be carried in a packet that has the same packet