Not sure I have a complete answer but here are my thoughts.
As you indicated, delayed ACK says that instead of sending an acknowledgment for every packet received, delay the ACK and send it for every 2nd packet but don’t delay it more that 500ms.
Window size sets a limit on the amount of data that can be sent unacknowledged. This is a key distinction between the two, one specifies the number of packets while the other specifies the amount of data. In practice due to mtu limitations tcp/ip packet size will be smaller than the window size or even half the window size of the receiving station. So the delayed ACK will be sent before the number of unacknowledged packets approaches the window size. But, the window size can of course decrease which is an important signal to the transmitting station, particularly if it is reduced to zero. This behavior alone makes window size an essential part of TCP. Also, while current mtu limitations keep packets small compared to a 65535 byte window size, the maximum size of an IP datagram is also 65535 bytes. It’s likely that when writing the RFCs the authors would have to take this into consideration and would create a standard that could support much larger packet sizes than we see in application today and, at least in theory, could fill up a window size in as little as one or two packets.
So I don’t think delayed ACK makes window size useless.