When I think of “texture array support” I expect full editor and material graph integration. Side-loading hand-crafted DDS files does not count as a proper PR IMO. Editor support would involve a new texture asset type, some sort of editor to manage the slices and the material nodes to access them.
Also, the engine already uses arrays internally (for example, reflection captures are stored in cubemap arrays). If the idea is to use texture arrays for high-performance terrain, simply throwing them on top of the existing permutation-based system doesn’t cut it and you’ll get little or no performance advantage: while you cut down the number of bound textures, if the number of draw calls and texture fetches remains the same, it’s no use.
The key of a texture array is being able to have the shader dynamically select which texture (slice) to sample from. For the UE4 terrain to take advantage of that, it would need to go through a paradigm shift like getting rid of the per-sector shader permutations and dynamically selecting the relevant layers directly in the shader, most likely using dynamic branching and looping.