Nicholas,
You raise some good points, and certainly there is always room for improvement in the SUM processes. In fact, I know that the team who work on this tool are constantly improving it, and this is some good feedback.
I was thinking more of the case where one is the Basis admin, i.e. one is the customer, and so in a position to make a strong case to management that effort should be spent on correcting this situation. As a consultant, your time is probably more limited, and this is likely not what you were hired to do. I still think you should make the argument to your customer that they need to spend time on cleaning up the situation (and offer your services at your billing rate to do so! 
), but I see your point that you may have more immediate concerns and need to keep a project rolling forward.
What I would do in this situation, where I had suspicions of such landscape inconsistency, would be to go through the objects in the SPDD and SPAU transports created during the DEV import and do version comparisons against the QAS and PRD systems. Naturally, you will need to compare the DEV versions from immediately prior to the SUM import, but that shouldn't be hard to do. If there are a great many objects, this could of course be rather tedious, but I think it would save you both time and a lot of headaches later when it comes time for the SUM import to the downstream systems.
This way you would have a list of the involved objects that aren't in sync and could develop a plan to fix the situation. Time spent at this stage working with the customer (perhaps researching old unreleased transports) to resolve these inconsistencies would, I think, be a wise investment. Obviously, the customer might not be interested in this, but I do think it behooves the consultant to at least raise the issue and advise on a best practice.
If the customer isn't interested in spending time on fixing this and wants to push forward with the support packs into QAS right away, then it will become extra critical that you do a SUM import into a system that is a copy of PRD, whether that is the QAS system or some sandbox system, and that you create your SPDD/SPAU transports from that system*. That way you will know that you have reliable modification adjustments captured in transports that you can safely use for the production import. Then, at some point later, the customer will need to go back and review/resolve the inconsistencies in DEV, but meanwhile you have gotten support packs through to PRD in a safe manner. Those QAS-created SPDD/SPAU transports could perhaps be used as imports to DEV to bring things into sync, eh?
If those inconsistencies never get resolved, then not only will the customer have this problem with every support pack and every upgrade, but any time they perform a modification in DEV of their own and transport it through they are at risk. Even developments on Z objects and configuration settings cannot truly be trusted in DEV, because you can't guarantee the system behaves the same as the rest of the landscape.
* Note that you might want to temporarily create a new transport layer with the QAS system as source so that it becomes easier to create and release transports from that system (not just local change requests that do no more than lock objects).
Cheers,
Matt