Well, Android Auto is proprietary as all get-out, it does what Google wants it to do and nothing else. Google is going to decide what it feels is safe to allow you to do for their own liability purposes, and most of that is going to revolve around Google's own apps and services. (Kinda like how Toyota has decided that it's unsafe for me to type in a phone number at more than 2 miles an hour, even though that's insane, and also locks out my ability to dial 911 while driving.)
And you do need a good car UI if you want to use something in your car, a normal phone interface isn't well suited to safe operation in a car. You want large, oversize buttons, large, oversized text, extremely high contrast (basically, throw Material Design out the window), and the key, where relying on random Android apps is going to fail: You want a unified UI across your functions.
A lot of other UI assumptions go out the window in a car, you need people to be able to interact with it, drop what they're doing, and pick it up again later, so you can't have things that time out or assume you are done with them. You ideally want people to be able to touch-feel some controls if possible, but at the least, you want minimal borders so people can aim for the center of a button and probably hit it without looking at it the whole time. Swipe is a complete no-go, you're in a moving vehicle.
So you don't want phone apps that aren't designed for a car really... at all, which removes most of the perks of using an Android.
I'd much rather build my own system that does the basics I need as quickly as possible than try to get a phone OS to be halfway safe in a car. Command line utilities on a Linux box thrown behind a simple UI screen is a pretty easy bet. (I'm running a Windows box, but I condemn myself at my own risk.)
If you're developing for yourself, you can get much further much faster writing simple code purpose-built to do what you want.