Most people will agree that the firmware on different layers is different levels of importance.
The idea that what matters is if it's in ROM or if it can be updated is the most bizarre boundary that I can imagine.
By far the most important thing is having the source to anything running on the main CPU
Next would be anything that can write to the memory without restraint (setting up an IOMMU that restricts where a card can write largely closes this one) because things can write to memory can interact with your main OS
For anything that isn't able to directly interact with memory is a peripheral of some sort.
The levels of openness on a peripheral are:
1. I can't use it.
2. I can use it only with some proprietary software that I don't know what it's doing.
3. I can use it with reverse engineered software, but I still don't know why the software is doing what it's doing.
4. the interface for accessing the device are documented so now I know what the software is doing and why
5. I can replace the firmware on the peripheral with reverse engineered firmware
6. I can replace the firmware on the peripheral with firmware that is using documented APIs of the peripheral internals.
I consider a peripheral that has the firmware in rom to be crippled as it forever prevents #5 or #6.
Almost all ARM devices are stuck at #2 (if they aren't at #1)
With this announcement, Raspberry Pi went from #2 to #4
Now, some people are complaining that the API to the GPU is a higher level than they would like. As far as I am concerned, as long as every OS that talks to this chip uses that high-level API, that's the appropriate API to put in drivers.
As a device designer, you may say that it's a bad API and choose to use a different device instead, but to declare that such an API should not be allowed into the kernel because it's too high level (like I've seen from some people) is wrong. High level or not, it is the API to the device.