The service is used for delivering you push notifications. Push notifications usually appear in the Notification Center in the top right corner of your desktop. Read more about it here:
http://support.apple.com/kb/ht5362
If you disable the service, you'll probably lose notifications for events such as received iMessage-messages, Facetime calls and notification from websites that you have requested notifications from.
From what you write, there does not seem to be a weighty reason for disabling it. It is a normal, system service that should not pose a problem to your system.
The connections in FIN_WAIT_1 state does not pose a problem to your system. You can safely ignore it (in those numbers).
You can also safely ignore the log message. The log message does not indicate that there has been a "data leak" as such.
The reason for the log message is that Apple uses a large number of servers for sending your push notifications. Your computer will connect to a (somewhat) random of those servers. The server will present a generic certificate for the service, and not one customized to the exact "sub-server" you have connected to. That is the cause of the log message. This is something Apple needs to fix on their servers, but it is a known bug and not something you yourself can do anything about.
This does not mean that you lose encryption or anything like that, but it might mean that your system could be vulnerable to a Man-In-The-Middle attack, where you could be sent falsified Push Notifications. Whether that is indeed the case would require further research. It is most likely that Apple employed some sort of certificate pinning or similar to avoid this type of exploit. The likelihood that you should be attacked this way is pretty low anyhow. I.e. don't worry about it.
I don't see why you say the daemon is "misbehaving". It is not misbehaving more on your computer than on any other computer. You could say that it is misbehaving, but it is doing so by Apple's design. So instead, create bug reports with Apple to let them know that you're seeing a problem.
Of course, if you do not actually use Push Notifications for anything, you can safely disable it.
Disclaimer
This answer is not intended as security advice for regular users. Setting your Mac's securelevel to 1 could potentially cause certain software or hardware drivers to malfunction, so I advise doing your own due diligence and independent research and testing to determine whether there could be any undesirable consequences to performing these steps.
Section 5.4.2 of the below-linked article about BSD's features related to security restrictions on the super-user is a good place to start. http://docstore.mik.ua/orelly/other/puis3rd/0596003234_puis3-chp-5-sect-4.html
In case that link breaks in the future, the most important section of the article lists the effects of setting kern.securelevel=1:
Write access to the raw disk partitions is prohibited. (This forces
all changes to the disk to go through the filesystem.)
Raw access to the SCSI bus controller is prohibited.
Files that have the immutable flag set cannot be changed. Files that
have the append-only bit set can only be appended to, and not
otherwise modified or deleted.
The contents of IP packets cannot be logged.
Raw I/O to the system console is prohibited.
Raw writes to system memory or I/O device controllers from user
programs are prohibited.
Some access is denied to the Linux /proc filesystem.
Additional kernel modules cannot be loaded.
The system clock cannot be set backwards. In addition, it cannot be
set forward more than a maximum of one second, and it can be set
forward only once per second (effectively, the clock can be pushed at
most to double time).
This list is not comprehensive.
TLDR: setting kern.securelevel=1 could have more consequences than what's described in the below steps. Be careful.
That said, I have tested out these steps on a regular iMac with OS X 10.10.2 and did not notice any problems as a result. In the past, securelevel 1 was the default setting for OS X, and manpages in OS X 10.10 still indirectly indicate that 1 is the default setting (they say you must reboot in single user mode to remove schg, which requires securelevel 0).
However, in reality, securelevel 0 has been the default setting since OS X 10.5. When the online community learned that Apple quietly changed the default to 0, some sysadmins on Apple Discussions threads called it "unconscionable" of Apple to do this. I've also found some security guides online that say setting kern.securelevel=1 is an important step to take for securing your Mac. YMMV.
Answer Summary
As long as you set a firmware password on a Mac, you can make any file on that Mac unable to be deleted by anyone, just by using this simple Terminal command:
sudo chflags schg /path/to/file
Next make sure your Mac will always boot to securelevel 1 by doing:
sudo vi /etc/sysctl.conf
Once in vi editor, type i to enter insert mode, then type kern.securelevel=1. Next hit enter, then colon, then type wq and hit enter.
Lastly in Terminal type:
sudo chflags schg /etc/sysctl.conf
sudo sysctl kern.securelevel=1
Now that securelevel is 1 and the schg flag is set, the file cannot be deleted unless the system is rebooted into single user mode.
If a firmware password has been set, you need that password to get into single user mode. Further you need it to get into target disk mode or change the startup disk.
With the schg flag set, even root cannot delete the file. Nobody can modify it from the Finder or Terminal. It will appear locked in the Finder, but the locked checkbox will always remain grayed out, no matter what, even with an admin password. In the Terminal, sudo rm /path/to/file will now fail, saying "Operation not permitted". Also, sudo SetFile -a l /path/to/file will fail with, "ERROR: Unexpected error. (-5000)". :D
To delete this file, someone will need to use the firmware password to reboot into single user mode, then unset the schg flag using this command:
sudo chflags noschg /path/to/file
After that it can be deleted.
UPDATE: Critical Extra Steps Necessary for Answer to Work
Update added Wed. 18 Mar. 2015 ~1:20 PM PDT: it came to my attention in the comments to this answer that someone with sudo access on the system could delete the protected file by renaming the /private/etc directory, then copying all its contents except the sysctl.conf file into a new /private/etc directory, and restarting. This would cause secure level to revert to zero.
To prevent this, after performing the above steps, you should also perform the following commands:
sudo chflags schg /private
sudo chflags -h schg /etc
The first command makes the /private directory and its subdirectories unable to be renamed. The second command makes the root-level symbolic link to /private/etc impossible to rename or delete. (The -h argument makes chflags act upon the symbolic link itself, instead of acting on the target of the symbolic link.)
Main Caveats
If you're on a Hackintosh or Mac Pro with an unofficial PC graphics card that has not been flashed with official Apple firmware or something functionally identical to that, this trick won't work. I am not sure if they can boot to single user mode, so if you establish the sysctl.conf file, and set it to schg, it may be like that forever. Which means any files set to schg can never be deleted.
There may be some physical ways to reset the firmware password by removing RAM or delete the file by removing the SSD/HDD and attaching to another computer.
Explanation of Answer
To set a firmware password for your Mac using the steps shown when you google, "how to set a firmware password on a mac". Briefly the steps are:
Explanation of Caveats
Note that on Macs with removable RAM, a hacker may be able to reset your firmware password by changing the amount of RAM, then clearing your PRAM a bunch of times. So on Macs like that, take appropriate physical security measures to prevent manual access to the computer's internal components.
Suffice it to say you must get to securelevel 0 for chflags noschg to work, and normally the only way to get back to securelevel 0 is to reboot in single user mode. Again this might be impossible if your Mac lacks Apple firmware. If you're paranoid/unsure, can see your current securelevel by typing sysctl kern.securelevel in Terminal; it should always be 1 after the steps have been followed unless you're in single user mode!
Further notes
As far as I know, and correct me if I'm wrong, but the only way around a firmware password (other than resetting it through the RAM removal trick) is to remove the primary hard disk or SSD from the computer in question, and access it from another computer using a SATA to USB adapter, or something similar. (Government agencies and/or Apple might have a secret, classified backdoor... but if they're after you, then you probably want to delete files, not prevent their deletion :D.)
So, technically speaking, setting schg only really solves your problem with 100% infallibility if you're on one if the newer Macs without replaceable RAM and without a replaceable hard drive (i.e. a Retina MacBook Pro, MacBook Air, etc.) and you set your EFI password, because those are the only Macs without removable RAM or a removeable SSD. (Of course if someone takes out your drive just to delete a file, again, you probably have worse problems, like, dude where's my hard drive?)
The 21.5" iMac's lack of "user-replaceable" RAM makes it a lot harder to circumvent the EFI password and steal RAM, which is probably why Apple made it that way, as it's intended heavily for use in schools where kids can and will circumvent any security measures :D (I know because in my day we used to hack right past AtEase on System 7 to play Marathon...)
On non-21.5" iMacs you can prevent the RAM-removal/firmware-password-reset trick by investing $40-50 in a Maclocks-brand lock for iMac. It goes into the security port and has a metal plate that covers up the power socket where the release for the RAM hatch is. With that physical lock in place, someone would need a diamond saw or similar to delete your schg-protected file... and if people are taking diamond saws to your computers then you have a lot worse problems to worry about than a file getting deleted, like, dude, where's my computer?
Best Answer
I'm not a developer or a guru in all of the available keys with launch daemons, but that is kind of a tall order as by design, root can do anything. I'm thinking you would basically be creating a security "virus" that would have a helper mechanism reload the daemon if it gets unloaded.