Good catch @enjoy-binbin
LGTM, two things:

1. The fact I missed addReplyDeferredLen() shows how bad this implementation is. Ideally we should have disconnected the client immediately after it sends the command because the command isn't marked with permission to be used from the replication link. In Make sure replicas don't write their own replies to the replication link #10020 We discussed this approach and decided it's too complex, but maybe now we can reconsider...
2. If we now have a functions for logging and async freeing the client (logInvalidUseAndFreeClientAsync()), then perhaps we should use it in all the other places it's appropriate, for example:
   

   redis/src/networking.c

   Lines 979 to 982 in a84c964

   	sds client = catClientInfoString(sdsempty(),dst);
   	freeClientAsync(dst);
   	serverLog(LL_WARNING,"Client %s scheduled to be closed ASAP for overcoming of output buffer limits.", client);
   	sdsfree(client);

   
   

   redis/src/networking.c

   Lines 1693 to 1695 in a84c964

   	serverLog(LL_VERBOSE,
   	"Error writing to client: %s", connGetLastError(c->conn));
   	freeClientAsync(c);

   
   ...

we can modify these other places, but i'd like to avoid changing the error message for the output buffer limit (maybe someone depends on it), and i'd like to avoid changing the verbosity level of the other one (may happen too often).
if we can't do that cleanly, i'm ok with keeping them as is.

1. Yes, the approach seems ok, but as oran said, indeed too much work... (this is uncommon)

2. I think we can take this one, although that looks like a good cleanup, like oran said, i think i will vote to keep it. (maybe in the future we can handle it better)