This looks like a format mismatch somehow, rtl_tcp outputs a .complex16u format. The attached signals, however, seem to be in a wrong format, there does not seem to be any information in it (most information is very near to -1.0 or 1.0).

Well, I agree it looks "mismatched" - the question is, what I can do about it? The only option I see which might actually have an effect is the sample rate itself but I don't see anything about the format?

rtl_tcp, an I/Q spectrum server for RTL2832 based DVB-T receivers

Usage:  [-a listen address]
        [-p listen port (default: 1234)]
        [-f frequency to tune to [Hz]]
        [-g gain (default: 0 for auto)]
        [-s samplerate in Hz (default: 2048000 Hz)]
        [-b number of buffers (default: 15, set by library)]
        [-n max number of linked list buffers to keep (default: 500)]
        [-d device index (default: 0)]
        [-P ppm_error (default: 0)]
        [-T enable bias-T on GPIO PIN 0 (works for rtl-sdr.com v3 dongles)]

Hmm, difficult to suggest a solution here! Apparently there are different versions of rtl_tcp and this version either doesn't record data in a clean way or is not compatible with the standard socket implementation used in URH. Can you have a look at the network trace to find out, if it is a problem on the network or SDR interface side?

But wouldn't other tools like rtl_433 and gqrx then also have a problem with a wrong transmitted data type? Or are they that forgiving?

I think I'll first try to build rtl_tcp from sources and check if that makes any difference.

Can I verify your assumption it's the wrong datatype with tcpdump/wireshark?

Well, the RTLSDR is not a real SDR but a misused DVB-T stick, therefore precision and so on is not as good as in "normal" SDRs, see e.g. the castrated I/Q format (.complex16u). There are tools optimized for this special RTLSDR (like those you mentioned) but URH is rather designed for real SDRs like the USRP or HackRF. I can image that those tools are more forgiving in consequence and maybe also have support for the latest RTLSDR hardware revisions (which may be not the case for default URH). I know, however, that RTLSDRs and also the TCP variant have been working for many years, because it was among others my part to implement years ago.
If you can observe the TCP stream in wireshark (I would prefer it over tcpdump here), you should predominantly see 16 bit (4 nibble) packages that consist of values near 00 or ff (i.e. -1.0 or 1.0 I/Q) if something with the data does not really work out.