Yes!
> I would suggest that the factory automation systems would be sensitive to downtime more than anything else
If somebody pulls some shenanigans on the sofware, which is responsible for actually building the cars I'd wager that such software is even more critical than the software in the cars.
Just imagine some twiddling with the break systems being manufactured.
So I don't believe downtime is the major concern. Security of the final product, which is directly derived from such software, is.
A car is a potential murder weapon. So yes. Especially considering it may be remote-controlled, and deployed by the millions.
And to those were wondering about robots sabotaging security sensitive car equipment: This should not be possible. In such situations you'll always two independent chains of control, one in HW and one in SW. In the car. HW breaks down eventually and SW is always partially broken.
Are they building highly sensitive software?
I would suggest that the factory automation systems would be sensitive to downtime more than anything else, and the ability to respond quickly with changes would be very valuable. Merging policies would only slow this down.
I would also suggest that there are many other internal tools, from machine learning infrastructure to small internal webapps, or supply chain management software that really aren't sensitive, and where the whole dev team having the _ability_ (whether that's used often or not) to push to master is advantageous.
Where is it not appropriate? Customer databases, HR tools, the autonomous driving software, perhaps?
Different development teams can work in areas with wildly different sensitivities and priorities, and in many cases it creates a better culture, faster delivery and more ownership to have developers able to push to master. Not always appropriate, but worth striving for when it is.