Unlike the article, I'd assume it's hardware related rather than software.

Assuming the article is correct and the hardware can do 7680x4320 @60, which requires 8GB/s memory bandwidth, in theory it should be able to do the same to read the same memory and interleave every other line for the down-sampling. However, it's possible that the new memory controller can't support 2 simultaneous burst streams (because the 2 lines are 30KB apart in memory), or if it's doing a single burst and buffering the first line until the second line is available, then maybe the cache is smaller than 30KB.

Another possibility is that previously the scale averaged pairs of pixel horizontally and cached them until the next line was available to average with that, and for some reason it was changed to average all 4 at the same time and so the cache isn't sufficient (although it'd be weird as 25.25KB is a fairly weird size to limit the cache to)

Alternatively, looking at clock rates needed for the sampler, 3360x1890 @60 is 381MHz, 3840x2160 @60 is 497MHz. It's quite possible that they've lowered the base clock on some hardware and not considered that it'd impact the maximum effect on the scaler.

But whatever IMHO, it's unlikely to be a software bug with an easy fix.

The 4 values in MaxSrcRectWidthForPipe are sub-pipes within each display controller, not separate display outputs. Every external display controller on the M5 Max has the same pattern: sub-pipe 0 = 6720, sub-pipes 1-3 = 7680. A single-stream 4K display only uses sub-pipe 0. Sub-pipes 1-3 are for multi-pipe configurations (8K displays use 2 sub-pipes, which is why an 8K EDID causes the DCP to assign PipeIDs=(0,2) with MaxPipes=2).

Your scaler clock theory could be right: the single-stream scaler path may genuinely have a lower throughput limit than the multi-pipe path.

Interestingly, the M2 Max uses a completely different IOMFBMaxSrcPixels structure. Instead of per-sub-pipe arrays, it has a flat MaxSrcRectWidth=7680 and MaxSrcRectTotal=33177600 (exactly 7680x4320) per controller. Every external display controller gets the full 7680 budget. Apple seems to have restructured the display controller architecture between M2 and M4/M5 to per-sub-pipe budgets, and the single-stream sub-pipe got a reduced allocation (6720 vs 7680) in the process. Whether that's a hardware change in the scaler or a firmware allocation policy is hard to say without Apple's documentation.