My my my. Perhaps someone here is being compulsively hard to please? Compulsively self-critical? Or maybe just a compulsive code reducer who doesn't quite understand yet what is meant by the ancient chant: "If it ain't broke, don't fix it"...

I don't see anything wrong with that code. The "repetitive" for loops make it clear that three distinct data sources are being used, and that these each have distinct amounts and types of information (as well as some common attributes), and yet each loop is compact enough to make it clear that the same general method of treatment is needed for each source (with the potential for minor variations per source). This strikes me as an optimal balance in the trade-off between what folks used to call "in-line vs. structured" coding.

To condense it any further would risk tipping the balance in the direction of obfuscation and more difficult maintenance. For example, you could try to "objectify" it in some way, but your current use of objects is already hiding a lot of hard work and a lot of design details -- a lot is left to the imagination for the "uninitiated" code reader (that is, the reader realizes that other sources need to be consulted in order to see what's really happening here). If you abstract further (and especially if you forget to add essential commentary/pod), everyone except you will be more likely to look at it and just say "Huh? What's this doing?"

The same goes for trying to use some sort of "uber" data structure (HoAo... or AoHo...) to shove the three different things into a single loop over that structure. I wouldn't do that in this sort of case, because the data structure won't be any easier to understand or maintain than the various for loops.

Sorry, I guess I'm not "helping" in the way you would like... maybe I'm just too old-fashioned.