Q :
" (...) if I run the zproxy.py and zpub.py scripts on one machine, and zsub.py on another machine (...) never prints anything."

Oh sure, it must do so -- just review the actual, imperatively commanded, connectivity setup :

Host A                                      Host B

     +-------+                           +-------+ 
     |       | zproxy                    |       |
     o========.bind("tcp://*:5559")      |       |
 +-->o========.bind("tcp://*:5560")      |       |
 |   |       |                           |       |
 |   |       |                       +-->?       |
 |   +-------+                       |   +-------+
 |                                   |    zsub
 |                                   +---.connect("tcp://{}:5559".format( getNetworkIp() )
 |                                        goes                        Host B ^^^^^^^^^
 |                                        onto                               |||||||||
 |                                        self ------------------------------+++++++++
 |    zpub
 +---.connect("tcp://{}:5560".format( getNetworkIp() )
                                  Host A ^^^^^^^^^

Q :
" Can anyone tell me what I'm doing incorrectly? "

(a)
repair the adresses accordingly, so as to indeed .connect() onto an RTO .bind()-prepared AccessPoint(s)

(b)
repair the error-blind distributed-code. There are many reasons, why naiive expectations may and do fail in real-world. Always test errno-indicated results from operations

(c)
better be nice to resources. There is no control of closing/release of instantiated sockets. That is wrong. Always release/dispose off resources, the more if gonna be used infinitely times, as above in an infinite loop.

(d)
last, but not least, your code should fail even on the localhost colocated run attempts, as the XPUB/XSUB-messages are (by definition, documented in native API, which Python wrapper might have put in shade) multipart. The code as-is shall block infinitely, as even the first arriving message ( being by definition multipart ) does not fully read-out from the incoming queue. One may find, even here, on StackOverflow, remarks on "robust"-provisioning for surviving (un)known-many-parts multipart-messages for production grade apps.