IIUC the benchmark above is somehow "biased"
The performance of sequential indexing into a view is more unstable than Array. A simple example

julia> a = randn(100);

julia> b1 = a[100:-1:1]; b2 = view(a, 100:-1:1);   # This is bad

julia> @btime sum($b1)
  6.900 ns (0 allocations: 0 bytes)
-13.657826292798031

julia> @btime sum($b2)
  30.282 ns (0 allocations: 0 bytes)
-13.65782629279803

julia> c1 = a[1:100]; c2 = view(a, 1:100);   # This is good

julia> @btime sum($c1)
  7.000 ns (0 allocations: 0 bytes)
-13.65782629279803

julia> @btime sum($c2)
  7.207 ns (0 allocations: 0 bytes)
-13.65782629279803

In this sense we'd better reduce the reindex layer when possible.

@N5N3 That is a good observation. Is that something the user can choose however at the point of creating the subarray, as they can either collect indexes into a fast container, or leave them in a slower view?

Is that something the user can choose however at the point of creating the subarray, as they can either collect indexes into a fast container, or leave them in a slower view?

Emm, user can always handle nested view manually if it does matter. In this sense, it looks the correct direction to avoid allocation if possible.

Note, #56760 was bisected to be caused by this PR.

Given the significant scope of regression in TTFX, we should probably revert this for now.

do we only want to revert the N dimensional case of this? The 1 and 2 dimensional version shouldn't be causing problems.

No, this is reproducible with 1-d as well. See my simultaneous MWE over at #56760 (comment). I think the better option would be to add yet more indirection and have reindex call a flavor of maybeview that uses copy-indexing if there's already more than one or two layers of SubArray.