One problem that I haven’t seen mentioned here with the suggested undefs is that it does not generalize beyond Array. zeros and ones have the same problem and before Julia 1.0 there were even plans to remove zeros and ones (see e.g. JuliaLang/julia#24444, JuliaLang/julia#25507) rather than adding more similar functions.
Julia and packages defined hundreds of different array types and there is no consistent way to initialize them, not even for getting a zero-array. For example, given FooArray, how do you instantiate one filled with zeros? A good guess is probably something like FooArray(zeros(n)), but i) that doesn’t always work, and ii) it also feels wrong to have to construct an Array first. It is true that in many cases there will be an Array backing the FooArray, but that should then IMO be allocated and managed internally and hidden from the user. StaticArrays.jl have “solved” this with macros (@SVector zeros(3) etc) which doesn’t actually call the Array-specific zeros function, but just like zeros this does not generalize.
The current Array{T}(undef, n) implementation came from the idea of having a general array “constructor interface” of the form ArrayType{T}(initializer, size, ...), but only undef, nothing and missing exist as initializers now. There were attempts to also have Array{T}(zeros, size) and Array{T}(one(s), size) as replacements or generalizations of zeros and ones, see JuliaLang/julia#24389.
Much discussion around this can be found in JuliaLang/julia#24595 and linked issues/PRs.