I don't think the design goals of QUIC and this protocol overlap too much. QUIC achieves lower latency for connection establishment than TCP+TLS by merging the TCP and TLS handshakes and avoids additional handshakes by being able to multiplex multiple streams over a connection. But apart from that it behaves a lot like "multiple TCP streams". It isn't designed purely for short-payload RPCs - streams can carry gigabytes of data. It's also not tailored to the datacenter use-case, and actually might shine more outside of it. And obviously QUIC is encrypted by default, while this protocol doesn't seem to be.
That said QUIC is rather flexible since implementations can be done in userspace, and a lot of what this protocol is about can probably be done by running a custom QUIC library. The GRANT messages can be emulated with window size increments on streams, and the retransmissions just look like different ways of handling ACKs - so this might be emulateble by having some custom ACK behavior and an infinite congestion window on the sender (bandwidth is limited by the receiver using window size increments). The usage of hardware-supported priorities might be a bit more tricky to map into QUIC - but it might be doable too if stream data frames can be sent in different UDP datagrams using different priorities.
Whether that really works better than the default setup? I'm not convinced. The nice thing about standard TCP and QUIC is that it works with all kinds of traffic. Congestion controllers will allow coexistence with other traffic on the links ("oh, there was a 5Gbit/s log upload or software update download which used 50% of NIC capacity?"), and the congestion window adjusting itself over time will also mean that "small RPCs can be sent without waiting for any confirmation". It even means "medium RPCs can be sent at once, once we learned about the link capacity (congestion window)".
That said QUIC is rather flexible since implementations can be done in userspace, and a lot of what this protocol is about can probably be done by running a custom QUIC library. The GRANT messages can be emulated with window size increments on streams, and the retransmissions just look like different ways of handling ACKs - so this might be emulateble by having some custom ACK behavior and an infinite congestion window on the sender (bandwidth is limited by the receiver using window size increments). The usage of hardware-supported priorities might be a bit more tricky to map into QUIC - but it might be doable too if stream data frames can be sent in different UDP datagrams using different priorities.
Whether that really works better than the default setup? I'm not convinced. The nice thing about standard TCP and QUIC is that it works with all kinds of traffic. Congestion controllers will allow coexistence with other traffic on the links ("oh, there was a 5Gbit/s log upload or software update download which used 50% of NIC capacity?"), and the congestion window adjusting itself over time will also mean that "small RPCs can be sent without waiting for any confirmation". It even means "medium RPCs can be sent at once, once we learned about the link capacity (congestion window)".