As a software guy I generally agree, but the idea that the software code and the configuration code are different is rather hair-splitting here, though obvious and important from system design and implementation perspectives.
That the code doesn't change just means that the formulas needed to manage that type of machine don't change from model to model. But the constants do. While it is normal and good for a software guy to think about data and code as being different, in this case it really doesn't matter. If they compile the constants into the code, or store them in some sort of separate memory, that doesn't actually change what they're building or how it interacts with the users. I know for a fact that some are using Harvard Architecture with physically separate storage for code and data, and in that case it is just the data portion that most people want access to. But still, both are probably stored on a single chip. So for the purposes of the DMCA, where it is the protection device rule that is at issue, they are the same. You can't access any of it without defeating the protections. If we had the exception for auto electronics, then the exact architecture used would affect the details of the Fair Use evaluation, but not by very much; once you get past the anti-access provision, whatever you need to interoperate is already Fair Use.
That said, I also know for a fact many ECUs do not use Harvard Architecture, do mix the code and data in the same storage, and people modify them by flipping bits in the binary to change the stored values. In that case the original value is literally compiled in. Sure, if you actually have access to the code it is just a different header file with those values. But just because software engineering practices encourage thinking about code and data as being different, in the actual implementation that is often an arbitrary distinction.
The real fear of the auto makers is that third-party ECUs could start to displace the vehicle brand, and people might start treating the body and engine as generic, and the ECU as the part that gives the vehicle its identity and performance tradeoffs. Instead of a "Ford Foo," maybe somebody is buying an aftermarket "Joe's FreedomCar (custom Foo model)" and then for their next car, they might get a "Joe's FeedomCar (custom Bar model)" based on a Honda. If they are also replacing driver instrumentation, they might really manage to change the driving experience enough to hijack the consumer association.
It is going to get much, much harder to stop all this when things go electric, because an electric ECU (MCU?) doesn't even need to be designed for a similar model motor; each feature can controlled entirely by sensor feedback, and the differences between ideal and actual parts can be detected by sensing voltage and current in different places. Existing third-party controllers already work easily with fairly random collections of home-brew parts. There is no complicated emissions technology to manage or worry about. If they want to lock us out, fine, in that case you can replace the whole controller.