Change:
7. <del> The cost of sending acknowledgments - in processing cost or link utilization - could be a significant proportion of available resources if these resources are constrained.  Reducing the rate at which acknowledgments are generated can preserve these resources and improve overall performance, for both network processing as well as application-relevant metrics. </del> <ins> QUIC version 1 without extensions uses an acknowledgment strategy adopted from TCP.  That is, every other packet is acknowledged. However, generating and processing QUIC acknowledgments can consume significant resources, both in terms of processing costs and link utilization, especially on constraint networks.  Some applications might be able to improve overall performance by using alternative strategies that reduce the rate of acknowledgments. </ins> 8.

Discussion:
There is text in the transport document on reducing ACK frequency. I think that that is sufficient. As this is more about performance tuning for implementers of the QUIC transport itself, it might be best to remove this section.
I am going to argue aganist this. It's a valid operational concern for a current network operator (at least any operator that does radio capacity assignment) and an apps developer. Although QUIC ACKs are something an endpoint might/ought to optimise, it was not really resolved in the core spec. QUIC can be more greedy on return capacity than TCP practically would when on-path mitigations are used.
This section was added based on comments from previous last call. I wouldn't want to remove it based on only one comment here. If more discussion is needed, we can bring it to the list.
I might agree with Martin. The document states "... Its intended audience is designers of application protocol mappings to QUIC, and implementors of these application protocols", and arguably the concerns about ACK frequency are not the concerns of the target audience. What can an application layer person do about this realistically? I don't think we they can change the app protocol design around this transport behaviour. That's not to say that the advice is bad. But I think the section would be stronger if it said plainly the caveat that Gorry just mentioned - applications using QUIC may find that the return traffic is more verbose than TCP, due to the differences in ACK generation and optimizations that have been applied.
I have mixed feelings on this, but I think there may be some things worth saying that are applicable to this audience. I think we need to change the existing text to clearly state that applications using QUIC may find that ACKs consume more resources, and cite transport if possible. Additionally, I think it's worth calling out that the ACK policy of QUIC v1 (without something like ACK-frequency) is designed to be similar to TCP, and may not be optimal for the full set of applications that QUIC can support. Realtime/WebRTC as well as VPN applications come to mind.
NAME there is also a section on ACK traffic in the manageability statement:
NAME NAME can anybody propose a PR? However, I think this would be a PR against the section on ACK traffic in the manageability statement if the intended audience is network operators.

For the applicability statement I created PR providing some more explanations. Does that help or do people still prefer to drop/move more considerations to the manageability statement? NAME NAME NAME NAME
Thanks for the PR, I think it's heading in a fairly good direction. But if people want to remove it from this draft, I'm not going to stand in your way.
This seems like it is in the right direction. I don't like how much text it adds though.For me, I think we are now so close ... I'd kind of like to see two paras, since these are two concepts, and it would be great to see both paras in the same section.