Nada, como eu posso ver.
O Linux man man page unix (7) diz que as permissões do diretório contendo um soquete se aplica normalmente (ou seja, você precisa de +x on /foo para se conectar a /foo/sock e +w on /foo para criar /foo/sock ) e a permissão write controla a conexão para o soquete em si:
On Linux, connecting to a stream socket object requires write permission on that socket; sending a datagram to a datagram socket likewise requires write permission on that socket.
Aparentemente, alguns outros sistemas se comportam de maneira diferente:
POSIX does not make any statement about the effect of the permissions on a socket file, and on some systems (e.g., older BSDs), the socket permissions are ignored. Portable programs should not rely on this feature for security.
unix(4) no FreeBSD descreve requisitos semelhantes. A página man do Linux não disse se o acesso ao socket em alguns sistemas ignora as permissões do diretório também.
Remover o bit x do socket parece ter o efeito de dar um erro diferente para tentar executar o socket, mas isso não é muito uma diferença prática:
$ ls -l test.sock
srwxr-xr-x 1 user user 0 Jun 28 16:24 test.sock=
$ nc -U ./test.sock
Hello
$ ./test.sock
bash: ./test.sock: No such device or address
$ chmod a-x test.sock
$ nc -U ./test.sock
Hello
$ ./test.sock
bash: ./test.sock: Permission denied
(Eu também testei que de fato apenas o w bit parece importar em acessar o socket no Debian 4.9.0.)
Talvez os soquetes que você quis dizer tivessem todos os bits de permissão removidos do usuário, ou você quisesse dizer o x bit no diretório?