While I don't know what exactly you've seen the TLS 1.2 explicitly states that application data must only send after the handshake is complete. This means that both sides has got and verified the Finished message from the other side. This is stated in various parts of the RFC 5246, like
Once a side has sent its Finished message and received and validated the
Finished message from its peer, it may begin to send and receive
application data over the connection.
Within a full handshake the Finished message is first send by the client and then by the server. This means that the client has to wait for the server to receive and verify the Finished message from the client and then send its own Finished message back. And only after the client received and verified this Finished message from the server it can send application data.
But, within a successful session resume the Finished message is first send by the server and then by the client. And in this case application data from the client can of course follow directly the Finished message from the client. From RFC 5246 page 37:
Application Data <-------> Application Data
Figure 2. Message flow for an abbreviated handshake
... that in some sites clients starts sending application right along with ClientFinished message i.e. after 1 RTT, while in some cases it doesn't and starts sending application data after 2 RTT
One possibility is that you've only noticed that application data from the client directly followed the Finished message but that you did not realize that this was because a session resume happened and thus the Finished from the server has already been received and verified by the client.
But, after you've edited the question and included an image it is obvious that this is not the case and a full handshake was done with early sending of application data. This is called TLS False Start and is defined in RFC 7918. According to this RFC TLS False Start can be done if the client has prior knowledge that the server is compatible to False Start and if strong ciphers white listed for use with False Start are used. For a short introduction into TLS False Start see High Performance
If 1 RTT was already there in TLS 1.2, then why there is so fuzz about 1 RTT in TLS 1.3?
TLS 1.3 changed the protocol a lot. The result of this was 1-RTT instead of 2-RTT for the full handshake and optionally 0-RTT instead of 1-RTT on subsequent connections (i.e. what was session resume in TLS 1.2).