The only choices to overrule the settings in /usr/share/kde4/services/ are either to delete hem directly (not good if you want to enable them again and also a package update will undo it), copy them to a ~/.kde/share/autostart under a user account and change them (changes will be persistent, reversible but we want to avoid user based changes),
http://blog.davidedmundson.co.uk/node/8 doesn't mention[font=courier] /usr/share/kde4/services/[/font]. Who claims the services folder can be overruled? I haven't found any references. Unless you successfully test this, it's more likely there is no overruling mechanism for[font=courier] /usr/share/kde4/services/[/font].
And hypothetically, if [font=courier]/usr/share/kde4/services/[/font] was overruleable by [font=courier]~/.kde/share/autostart[/font], it would likely be overruleable by [font=courier]/etc/xdg/autostart[/font] and [font=courier]/usr/share/autostart[/font]. In that case, why do problematic writes to user home and not rather use any of the two latter?
Not mentioned but we can go for the first option and instead of deleting the .desktop file it will instead be patched by a startup script that adds the hidden option. That way the changes survive updates, could be turned off by disabling the patching and are system wide without getting into user specific settings problems.
Inventing a patching system is hard. That effort would be better spend on the real solution.
I'm thinking a a systemd service that automatically deletes the applet desktop file under the services folder and could be stopped if a user wishes to see the applet.
The problem with these approaches is that they are surprising, non-standard, hacky, creating confusion, requiring documentation and looking dilettante when you explain them "we haven't figured out how kde [url=https://techbase.kde.org/KDE_System_Administration/PlasmaDesktopScripting#Remove_a_widget_from_systemtray]plasma shell scripting[/url] works, so we invented this custom patching system, that you can disable by...".
We haven’t contacted the author of the solution that worked for wheezy.
Maybe that way can be fixed for jessie. Maybe just the string “org.kde.networkmanagement” changed to something else and this would be fixed.