можно ли вообще считать ошибкой печально известную ошибку `ERROR_NETNAME_DELETED'?

Это полностью зависит от вас, как вы относитесь к состоянию ошибки. В вашем случае это состояние ошибки вполне ожидаемо, и вы можете совершенно безопасно рассматривать его как ожидаемое состояние.

Другим примером такого рода является случай, когда вы вызываете функцию API, но не знаете, какой размер буфера предоставить. Таким образом, вы предоставляете буфер, который, как вы надеетесь, будет достаточно большим. Но если вызов API завершается неудачей, вы затем проверяете, что последняя ошибка — ERROR_INSUFFICIENT_BUFFER. Это ожидаемое состояние ошибки. Затем вы можете повторить попытку с большим буфером.

Вам решать, как обрабатывать состояние ошибки, но вопрос является признаком потенциальных проблем в вашем коде (от логических ошибок до неопределенного поведения).

Наиболее важным моментом является то, что вы не должны касаться дескриптора SOCKET после closesocket. Что вы делаете в EOF? Было бы логично closesocket на нашей стороне, когда мы обнаружим EOF, но это то, что вы не можете сделать в ERROR_NETNAME_DELETED обработчике, потому что closesocket уже произошло и дескриптор недействителен.

Также полезно представить, что произойдет, если ожидающее чтение завершится (с доступными реальными данными) непосредственно перед closesocket, а ваше приложение обнаружит его сразу после closesocket. Вы обрабатываете входящие данные и... Вы отправляете ответ клиенту, используя тот же дескриптор сокета? Планируете ли вы следующее чтение на этом дескрипторе? Все это было бы неправильно, и не было бы ERROR_NETNAME_DELETED, чтобы рассказать вам об этом.

Что произойдет, если ожидающее чтение завершится с EOF в этот очень неудачный момент, как раз перед closesocket? Если ваш обычный обратный вызов OnEof запускается, а этот обратный вызов выполняет closesocket, это снова будет неправильно.

Описанная вами проблема может указывать на более серьезную проблему, если closesocket выполняется в одном потоке, а другой поток ожидает завершения ввода-вывода. Вы уверены, что другой поток не вызывает WSARecv/ReadFile, пока первый поток вызывает closesocket? Это неопределенное поведение, даже несмотря на то, что winsock делает вид, что работает большую часть времени.

Подводя итог, код, обрабатывающий завершение (или сбой) чтения, не может быть правильным, если он не знает, что дескриптор сокета бесполезен, поскольку он был закрыт. После closesocket полезно дождаться ожидающего завершения ввода-вывода, потому что вы не можете повторно использовать структуру OVERLAPPED, если вы этого не сделаете; но нет смысла обрабатывать этот тип завершения, как если бы это произошло во время нормальной работы, когда сокет все еще открыт (код ошибки/состояния не имеет значения).

Вы вызываете неправильный метод. Вы должны вызывать WSAGetLastError(). Результат GetLastError() после вызова Winsock API не имеет смысла.