... if some server sent me illegal content that I did not ask for, they could incriminate me for having that content later and I do not have any proof that it was they that send me this content.
You can neither proof that somebody has send you some content nor can someone proof that someone has not sent you this content. Also, if someone sends you incriminating content they most likely don't want you to be able to proof this anyway and thus would not use a transport method which lets you proof this.
I would not expect the server to sign every application data exchanged ... but why not signing a hash (or a HMAC with the session key) with the private key of the server at the end of the communication? If both parties sign it, then as I see it, they both obtain benefits.
This was simply not a design goal of TLS. TLS is designed to protect against sniffing or modifying by some man in the middle, not that some party can prove that the other has sent something. In other words: TLS is not a secure everything you want protocol but has a specific goal - which is not the goal you expect from it.
Additionally, in order to let both parties sign their sent data both parties need to have a certificate. While certificates for server are the most common case (but it can be done without, like with PSK) certificates for the client are uncommon.
Also, if the signature is only added at the end of the connection as you propose the peer might deliberately or accidentally close the connection before the signature was sent. It is common though that the data gets already processed while more data still get received - which make it possible to incriminate you but make it impossible for you to proof it.
but why not signing a hash ... with the private key of the server at the end of the communication?
The purpose of certificates inside TLS is for authentication (and maybe key exchange - but this is deprecated and removed in TLS 1.3). Authentication needs to be secure at the moment it is done and thus the certificate needs to be sufficiently secure for the moment.
Signing instead should provide proof long after the data where transmitted. This means that the certificate might need to be stronger (depending how long the proof should be fine) and that the private key of the certificate needs to be protected for as long the proof should be fine. If the private key is not guaranteed to be protected that long somebody else might create faked signed messages or might successfully claim that what you present is faked.