SQL Server 2014/2016 (Win2K12R2) and Winsock limits - how to cope?
The information presented here makes it look likely connections are rejected due to the TCP backlog queue being full of partially opened connections. The other item I ask folks to double-check in cases like this is that MPP (Memory Pressure Protection) is either globally disabled, or disabled for the SQL Server listener port.
As you indicated, SOMAXCONN is the value passed in when the SQL Server listening socket is opened to give the queue depth for the backlog queue.  Unfortunately, as you're probably aware, up through Windows Server 2019 SOMAXCONN is not exposed or configurable to administrators, but is instead set to a &quot;reasonable value&quot; by Windows.  Although I've not seen documentation for how Windows determines this value, I imagine it increases as RAM on the system increases.  CPU count may also  play a role.
One way to explore whether it is a TCP backlog queue full of partially-opened connections is by counting connections in the SYN Received state.
For example the following powershell will give counts for connections in each state for each (LocalPort, OwningProcess).
Get-NetTCPConnection | Group-Object -Property LocalPort, OwningProcess, State | Select -Property Name, Count | Sort Name


Unfortunately, while trend of connection counts will be helpful, without knowing SOMAXCONN it may not be definitive.
Unfortunately Windows does not provide the TCPExt stats in 'netstat -s' output; 'resets received for embryonic SYN_RECV sockets' could be especially useful here.
Without knowing the formula or resulting values for SOMAXCONN on a system, it's hard to know how much RAM would result in a higher SOMAXCONN value and more breathing room for partially opened connections. You mentioned a system with 2TB of RAM saw similar connection failures, it's likely you won't get much larger of a SOMAXCONN value than that.
And if the connection burst can't be throttled or capped at a lower maximum, then the only intervention with reasonable confidence is trying to speed up getting connections through the process.  Eliminating any use of paging space if present can help.  In a VM, oversubscription of CPU or memory can hurt (by slowing down connection completions during a connection burst).  In some cases RSS can help, but you noted that has already been tried.  WFP filters (Windows filtering platform) such as anti-virus and anti-malware can add overhead to connection completion; so any WFP filters in use may warrant review.
Use High Performance Power Plan rather than Balanced Power Plan.  If a connection burst immediately follows a period of low activity on the target server, the CPU will be starting to complete partially opened connections at a lower clock speed and this can contribute to a full backlog queue followed by connections denied.