OK, here is what I think you are saying: The compiler cannot check that the promise made by the type parameter spefication of the abstract type is realized in the implementation of the type (i. e. the concrete type). That is why it does not use the information about the type parameter that it can see in the definition of the abstract type.
It might be worthwhile to spell this out (if I am right, of course) in the documentation.
There doesn’t really exist any “promise”, only a convention (made by humans) of what the two type parameters should mean. From the compiler’s point of view, AbstractArray{T, N} is just an abstract type with two parameters, like Foo{A, B}. What these parameters mean must come from the documentation.
I know this is a 2 year-old thread, but this is an interesting discussion on why abstract-type fields are not supported: Julia issue #4935. My understanding, as others mentioned, is that abstract types are helpful to define expected function interfaces (multiple dispatch) for derived types. In that discussion they separate between behavior inheritance (supported) and member inheritance (not supported).