There is no reason why C++ can't provide a lengthof(x) function that returns the length of arrays allocated using new[], since the length needs to be stored internally anyway -- otherwise delete[] wouldn't know how many destructors to call. It would also be great if there was a realloc() equivalent that did the right thing with regards to constructors/destructors, because it's not possible to build this functionality on top of C's realloc().
new[] and delete[] are frustrating. If you "typedef int X[5]", how do you correctly free one instance of X - "delete new X" or "delete[] new X"?
The problem is that vector<T> isn't great either. Only C++03 made it legal to assume that vector<T> has contiguous storage (which is critical when interfacing with C APIs), and only C++11 made it possible to transfer vectors without expensive copies. But using rvalue references and copy elision correctly is certainly not trivial, and using vector<T> as a building block for your own data structures is in some ways more frustrating than using new[].
I think C++ should deprecate new[] and delete[], add a library function std::realloc_array<T>(ptr_or_null, length) that can be used to replace new[]/delete[]/realloc() and another library function std::array_length(ptr), and then vector<T> and other data structures could be built on top of that with little overhead. But I don't see it happening.
C++ has bounds-checked arrays that know their length if you want (hello, std::vector<T>, or roll your own if you don't like that one). It just doesn't endow the C arrays with it (for good reasons). The C compatibility of C++ means that C++ interoperates easily with C API's without the overhead of FFI.