But if Server’s certificate is checked sucessfully by Client, how is
it possible to consider that Server has been authenticated by Client,
while at this time none message signed with Server’s private key has
been sent to the Client and verified by it ?
If only consider the key exchange to be what the RFC says it is, then yes this key-exchange can be broken by an attacker having the right certificate.
However this is not how TLS works in practice. In practice you'd never stop after the ClientKeyExchange message as you have set-up the connection to actually do something. This is why most formal analysis considers ChangeCipherSpec and the Finished messages as part of the key-exchange for their proofs.
And it only matters that the server is successfully authenticated after they complete key-exchange, not at some "randomly chosen" point in the protocol.
The exchange turns out to be secure and properly authenticated by verifying the Finished message which contains a MAC on all previous (handshake) messages. Because a fake server can't decrypt the pre-master secret and hence can't compute the master secret, he can't compute the neccessary MAC and the client will respond with a fatal_alert, killing the connection.
I don't know why the designers of TLS chose this "through the backdoor" authentication method but I can only guess they wanted to avoid yet another computationally intensive private key based operation for the server.
TL;DR: The finished message gives you authentication with its MAC only being available to the private key holder.
Is it correct to talk about "Authentication by Certificate"
(assuming based on Certificate verification via CA root public key)
instead of authentication via digital signature?
You never authenticate by only presenting a certificate.
The only situation where you may do it is with secure tokens holding key-files to access some physically restricted facility where the tokens will never actually be plugged into a real computer (aside from new file assignment).
In an internet-based scenario you'd never do this as every eavesdropper could impersonate the owner of the certificate, rendering it completely useless.
What TLS does (and may be meant by your question) is encryption-based / certificate-based authentication. This is basically some sort of challenge-response protcol, where you send some party a random nonce and an asymmetrically encrypted key and expect the MAC on the nonce using that key as response. One can do that, but this is rather "abusing" the encryption to do things it was not intended to, as we have dedicated constructions for that: digital signatures.
So usually a designer would rather go with a digital signature and an encryption ( / decryption) (or even better DH) as today it's pretty cheap to do both operations, whereas you may need to use the encryption based approach for very constrained devices where only one such operation is "allowed" / feasible or where actually can't perform signatures (by padding, rather unusual).
TL;DR: Solely certificate based authentication is bad and only feasible in physical access restriction scenarios and otherwise you can do challenge-response with encryption but should prefer signatures.
