Type parameters are only used within the compiler, so there is no intrinsic speed or memory cost to a Int64 parameter over an Int32.
Further, canonicalizing the length parameter to a uniform type actually seems very important here. Unsurprisingly,
julia> SizedVector{Int64(3),Float64,Vector{Float64}} === SizedVector{Int32(3),Float64,Vector{Float64}}
false
So, even if non-Int parameters were accepted and you could create the object, it might struggle to interoperate with objects that used a differently-typed type parameter. It would also miss methods for things like LinearAlgebra.cross, which is defined only for objects with Size{(2::Int,)} and Size{(3::Int,)}.
I think that these codebases just get much much harder to write and maintain if they allow non-canonical representations like this. If it mattered, people could eventually support this, but again these values mostly exist within the compiler so there’s little value to adding this support.
StaticArrays.jl is far from alone in this lack of support:
julia> NTuple{Int32(3),Int}
ERROR: TypeError: in Vararg, in count, expected Int64, got a value of type Int32