You can do that, but if keep alive are not synchronized (I don't think there is a mechanism to do so), you will wake more often if you keep more connections open.
I think the OS could synchronize them if keep alive packets are sent at the TCP level, but that would be hard to do at a higher level.
Letting a single program handle persistent connections leaves a lot more potential for energy efficiency optimizations.
Google famously tried allowing app keepalives to be synchronised... The scheduler allowed a wakeup in 'approximately' X minutes, and the OS would wake up and run all apps callbacks at once. If any app needed a wakeup at a precise time, then other callbacks at nearby approximate times would be run at the same time too.
Overall, the thought was that wakeups are expensive, wakeups that involve the network are particularly expensive, so might as well run them all at once (they tend not to be CPU bound - often much of the wakeup handler is spent waiting for the network to connect and send a packet or an ack to arrive back).
This turned out to be a very very bad idea. All it takes is some app to have a 'wake up exactly on the hour', and now all other app callbacks will also run exactly on the hour. End result: Mobile networks get 10 million phones all waking up within a few milliseconds of one another, and everyone wanting to connect, and the whole mobile network fails because it was never designed to have 10 million phones all trying to connect within a few milliseconds.
Unfortunately there are lots of bits of hardware in mobile networks that fake acks - ie. TCP level acks will be received very quickly to indicate the mobile network has accepted the data, and will deliver it at some future time out to the internet.
The problem is they still send acks even if the remote end is no longer responsive.
So you can't reliably use TCP acks to know if a connection is still alive. You need to send actual data and have the application respond.
I think the OS could synchronize them if keep alive packets are sent at the TCP level, but that would be hard to do at a higher level.
Letting a single program handle persistent connections leaves a lot more potential for energy efficiency optimizations.