Yes, it has dramatic impact on the battery life.
Wi-Fi in lower power state, when it has nothing to respond to, disables power amplifier and only listens to incoming data. Some functions which are usually performed by the OS are offloaded on smartphones to the Wi-Fi chip, such as ARP/NDP replies, so it doesn't need to wake up a CPU to perform simple answers.
However with the constant keep-alive it has to both enable power amplifier and to wake up the CPU to send the reply that the socket is still alive.
I have a single-board computer with and old Mediatek chip (10 years old), and there Wi-Fi PA increases power consumption by 200mW.
Another reporter in the ticket told that his smartphone works basically 1/2 of its common battery life with KDE Connect enabled.
Keep-alives (not necessary TCP keep alives, but any of this kind of packets) are the _MAIN_ reason for internet battery drain while idle, and are tricky to debug if you don't know where to look (Android lists it as "Android System" or "Phone Idle")
For example, Golang applications had 15 second keep alive until recently: https://github.com/golang/go/issues/48622. Imagine you've opened the website which uses golang web server/proxy and enabled notifications from it in the browser, which use WebSocket from the website itself. Now every time your CPU is woke up every 15 seconds until you close the page and notification channel is offloaded to google/mozilla servers. And remember: every TCP connection has its own 15-second Keep-Alive in different intervals, so it's more like 5-7 second CPU wakeup interval.
The same applies for VPN. When anybody say that anways-on VPN connection drains battery, that is 90% if the time is due to frequent keep-alive packets from the VPN server.
Everything above applies to cellular connection as well, it's the same principle.