I think part of your expectation may be coming from Java, where only fundamental data types are stack allocated and everything else has reference semantics to heap-allocated objects.
For the sake of syntactic consistency, one could argue that C++ should mandate "()" as a suffix to declarations to invoke the default constructor. However, what good is an allocated object that's _not_ constructed? For many classes, of course, the default constructor is trivial, but for others it isn't. The purpose of the constructor is to provide invariants that the code can rely on--it isn't obvious to me what common use case you could consider for an object that's allocated on the stack but not constructed, and it seems like it's asking for trouble.
Also, since C++ inherits C's syntax and semantics for fundamental types, "int i;" must be legal. So we cannot abolish the form.
For the sake of syntactic consistency, one could argue that C++ should mandate "()" as a suffix to declarations to invoke the default constructor. However, what good is an allocated object that's _not_ constructed? For many classes, of course, the default constructor is trivial, but for others it isn't. The purpose of the constructor is to provide invariants that the code can rely on--it isn't obvious to me what common use case you could consider for an object that's allocated on the stack but not constructed, and it seems like it's asking for trouble.
Also, since C++ inherits C's syntax and semantics for fundamental types, "int i;" must be legal. So we cannot abolish the form.