Hi,
you've heard right (and as usual there always is a more comprehensive answer): Booting from an .scr file isn't recommended (if you have the choice to boot a binary config/.cnf) for at least these reasons:
1. it can take significantly longer (depending on the number of lines in the config / number of ints)
2. interfaces might not get operational in the "right" / desired order (customer facing ints might come up before the core-facing ones) / protocols might not be started when you'd want this
3. there have been (and may still are some) issues that not all elements in the .scr-file / show conf output are in the right sequence, so you might get an error message saying that a certain config-statement can't be applied, as it's referring to an element that doesn't yet exist
How to deal with this:
1. in case of a downgrade you have no other choice then loading the .scr as there is no way that new.cnf will be read by the old release
2. you could edit the .scr file and change the sequence so that e.g. core- and management-ints are created first, then all protocols are started/configured and in the end the customer facing int's are configured
3. you possibly could go through the config and try to find these "out-of-order" statements, but thats rather time-consuming (as you stated you have a lab-system to try this out, you'll see if there really are issues and then you can fix these along with 2.)
Hope this helps.
Ulf