For release architectures built by the the debian.org build services I agree that out of date packages should continue to be prioritised. If due to short term conditions a release architecture is behind on building then it's usually* more important to keep packages up to date so they don't block testing transitions than it is to attempt to build packages the architecture has never built before.Right now, we have the problem that an upload of a > previously compiled source package that’s “totally unimportant” will be > sorted before all source packages in state “uncompiled”. Only if we also get a waiver that allows testing to go out-of-sync for these arches. Otherwise, no thanks.
If a release architecture is getting behind on building on a long term basis then IMO either more buildd hardware should be obtained or the port should lose it's release status.
But that isn't what we are talking about here, we are talking about an architecture that was kicked out of testing and kicked out of the official archive years ago, degraded to an almost unusuable state and is now attempting to become usable again. For them it's probablly far more important to build as many "important but not yet built" pckages as possible than it is to make sure every package they have built is up to date.
* Though there are corner cases where a new package is actually pretty important because some other package has been updated to have a dependency on it.