Keep the questions coming, Simon. I am sure more people are asking the same questions. :-)
Unless you're a magic worker, you will have logical bugs waiting to be discovered as soon as you test your code against the customers own data. Most likely, your development environment will be with less or outdated data. I reckon that is why there is this notion of fixing things in TEST and applying these fixes back to DEV. Since there is a high chance these changes will impose new element IDs, making each of these environments stray away from each other, it will not be easy to push the business data back and forth.
If your customer/project allows for a dedicated STAGING or BUILD environment, then this would be the place you prepare your compiled modelstore.
I have split this in PROD, TEST (or UAT) and DEV on the customer site. Then there will be in-house DEV environments for various solutions I work on. I keep element IDs equal in PROD and TEST, but DEV will over time get more and more different IDs. Reason is simply that completed code gets moved from DEV til TEST using models, and models will only contain the Origin ID (GUID), and not the element ID and element handle.
I still recommend having a BUILD environment for the customer, so you can build and prepare a modelstore without having to kick out the consultants from the customer TEST. This is probably more critical before a Go-Live, and after a Go-Live the cycle of pushing changes to Prod will slow down (hopefully), reducing the need for a dedicated BUIILD environment.
As you probably know, one of the strengths in AX is the low threshold for making changes to the application (using the AOT). This is in the blood of the consultants, and they expect developers to be able to push changes to the business logic in a short and quick cycle.
As developer, you know AX2012 can easily be broken if all dependent elements aren't properly compiled and CIL compiled. You also know a full compile takes hours.
As responsible for the technical architecture you want the developers to work efficiently AND the consultants to be able to work efficiently. Having them to wait for each other will just stall everything. :-)
Again, sorry for the wall of text.