Intents are the best permissions system.
I work with hardware that comes with stock AOSP, and getting a "daemon" style service to run from boot without closing took several workarounds, even though it should have been as simple as "START_STICKY" with a foreground service Android's Service model is very clearly not meant to support such a simple usecase. The most reliable way is actually to modify the image because only system services are supposed to be allowed to do that.
Working with services that aren't reliably started can also be bad for UX even if you don't have the usecase I had of needing a daemon because there might be a high cost associated with starting up. People also don't want every service showing a notification to stay alive.
After trying to model this complex device management system I was working on in nice contained pieces we could maintain separately, I was forced to stuff it into one monolithic app. Performance improved because we no longer needed workarounds to keep the multiple services alive, just one was enough, and we only needed one process to stay alive (a process which is always second from the top in recent usage because our hardware only needs to run our app and a 2nd party one).
Intents are unstable because no one follows the standards for verbs properly. Samsung's built in apps are notorious for crashing if you try to use extras. Facebook won't crash, but it won't respect EXTRA_TEXT or EXTRA_SUBJECT properly because they only want you sharing a URL. Pinterest crashes on sharing some images that other apps don't.
I'd almost go as far as saying you can find a crash report that's app-specific for any major app (Gmail, Facebook, etc.) that you'd expect to see receive a share intent by googling "<insert app name> android intent crash". It's almost always something with the app that's taking the intent not respecting the intent contract properly.
On top of all that, the usual reason there is a "high cost to starting something" is that it hits a server and hasn't cached the data it needs. The OS can't solve that for you.
Our service really is the most important service on the device because if our service goes down the device is essentially "bricked" (these are embedded android devices so we lose visibility on the installation), but adding our service to the image means managing images for every device variation we use (and some of those device's manufacturer's won't be happy to have someone else managing said images since it means more work for them [build image, send it to us, we modify it, send it back to them, they use it vs just building an image and using it]).
It's a unique use case, but it's not hard to imagine more common software that could take advantage of daemons, even if it's just to provide smarter background processing than the "all-or-nothing" defaults provide (like START_STICKY). Besides being rather unique to our use case, I'd also say it doesn't have to do with apps from different creators working together...
And I don't think the network is involved most cases of expensive services, because the OS (or more specifically, Google's services on most end user devices) already help solve that with things like the GCMNetworkManager and ConnectivityManager callbacks for optimizing network access.
I would put a service-starter service in the device images. I see that might be a problem, too, because it seems like you are only "lightly embedded," with multiple hardware platforms. But this could be a really lo-impact thing for your hardware partners and relatively clean. Alternatively, provide a modified launcher, if you are not already replacing the launcher with your own embedded app, that tickles the service on startup. There are probably other advantages to having your own Home app if I understand your situation correctly.
Google has to be heavy handed because too much mobile development is crap, and a low-bidder contract development shop wouldn't hesitate to take the anti-social way to an implementation if they could. The road to hell is paved with cheapass outsourcing.
I also tried some tricks with replacing the launcher since we have full root access, but the launcher process was getting killed almost as often as our custom services.
Since I moved to a single-process model I've had fewer killed services, but we still have the AlarmManager kicking them off just in case.
A lot of the moves Google's been making, from shutting down file uris for content providers feel like they're meant to shut down the "easiest way out for developers", things that are easy for devs, but bad for the average mobile user, but they're also hurting Android for other usecases. I guess the plan is to push Brillo for that, but being able to leverage Android's ecosystem on embedded has some advantages
Point of sale system?