The problem is the other way around.

A: Can you hear me? B: Yes B: What time is it? A: ...

At the point that B has replied Yes, B knows that it can hear A and that it can send to A but it doesn't know that A can hear B. As long as A makes the first move in the rest of the conversation that's fine - the next message from A confirms that B's "Yes" was received, but if A has nothing to say then B has to send it's next query and hope that A received the Yes successfully. If it didn't then B thinks the connection is established but it actually hasn't been.

Isn't the whole point here that handshakes are cheaper compared to the actual content? If you use the content as the handshake itself, you can end up with huge content only to find out that the conversation didn't work.

That conversation can also go like;

A: Can you hear me?

B: Yes

A: What is the full unabridged story of War and Peace?

B: <...>

A: I am going to a take a nap for now, goodbye!

B: ... Goodbye!

TCP is two way and in your example B has no idea that A can receive the messages it is sending. Example: What if B needs to ask A about the date in the same conversation, it doesn't know for sure it would get a reply (it can try but that's not TCP then).

Well there the “what time is it?” serves as the “great, I can hear you too!” but I take it that the point is that B needs some reply from A to know that they can hear them.

You could also just start with "What time is it?" and see what you get back, right?

I believe that's UDP. :)

it ? is time What What ?

Who is this? What? No! You called me!

But person A might not be ready to ask a question, and person B doesn't want to wait around forever to have a conversation with someone who might not even be able to hear them.

Both sides need to know to "commit" to the connection.

TCP Fast Open does you one better:

A: If you can hear me, what time is it?

B: Yeah I can hear you; it’s 5.