Implications of using PostgreSQL COPY command to stdout and then immeadiately reading it from stdin
The drawback is that if the operation fails part way through due to network hiccup, a reboot of HOST1, or something like that, you've done a lot of work on DB2 that needs to be rolled back and repeated.  This can blow up your WAL archive, and can lead to table bloat if you don't vacuum the table in DB2 before repeating the operation.  I'd spool it to a local-storage file on HOST2 first, unless I had a good reason not to.

Most of the caveats you link to are about PostgreSQL interpreting the data format in a different way than Excel, Python, Perl, human beings, etc. might interpret it.  Going PostgreSQL to PostgreSQL (either with a pipe or using a file intermediate) eliminates most of those caveats, assuming you choose the same options to \copy on each end and have the same table structure.  The caveats about performance and foreign keys, however, remain.