I'm not sure how much you'd gain by implementing a onepass resizer.
First of all you get massive overhead, since you'll most probably run out of free registers due to the added complexity.
It would also mean you would have a very non-liniear memory access pattern, which can result in penalties - all of us who has written a spatial smooth filter knows how it is.
Whoever wrote the current resizers did a very good job - it's very fast and very flexible.
The horizontal also has per-line unpacking, which speeds up the process massively - this could also be implemented in a one-pass resizer, but you'll probably run into many cache-misses, if your unpacked data gets larger then half the cache size. Otherwise, you'd have to unpack x-lines ahead.
I think you could gain up to 25% by doing a onepass resizer, but I did a profile a week ago on a script, that loaded an MPEG2 file, resized (using lanczos), did Fielddeinterlace() and saved out the result uncompressed using fast repack in vdub.
The resizer took ~ 15% of the total CPU time, so in a typical repack as this would gain 4% encoding speed - (and using bicubic and an MPEG4 compressor, the gain would probably be <2%). IMO not worth the massive complexity of writing a onepass resizer.
(hope this made any kind of sense
)