Q:

ANSI C - direct-declarator grammar - Why does the C grammar allow syntactically legal, but sementically illegal declarations like int func()()?

The ANSI C grammar specifies:
declarator:
    pointer_opt direct-declarator

direct-declarator:
    identifier
    ( declarator )
    direct-declarator [ constant-expression_opt ]
    direct-declarator ( parameter-type-list )
    direct-declarator ( identifier-list_opt )

According to this grammar, it would be possible to derive
func()()

as a declarator, and 
int func()()

as a declaration, which is semantically illegal. Why does the C grammar allow such syntactically legal, but sementically illegal declarations?

A:

These kinds of questions typically can't be answered for certain, because you're asking for information about the collective thoughts and deliberations of the C committee, in 1989.  They've never conducted the work of language development wholly in public, the way, say, the people responsible for Python do, and thirty years ago they did that even less.  And if you polled them personally, they probably wouldn't remember.
We can look at the C Rationale document (I'm linking to the edition corresponding to C1999, but as far as I know it didn't change very much since 1989) for clues, but on a quick skim, I don't see anything relevant to your question.
That leaves me making guesses based on general principles of programming language design.  There is a general principle relevant to your question: Particularly for older languages, designers try to make the formal syntax be context-free as much as possible.  This makes it much easier to write an efficient parser.  Rules like "you can't have a function that returns a function" require context, and so they are left out of the syntax.  It's straightforward to handle them as post-hoc constraints applied to the parse tree instead, so that's what designers do.
The C grammar has a whole bunch of places where this principle appears to have been used, not just the one you're asking about.  For instance, the "maximal munch" rule for tokenization exists because it means the tokenizer does not need to be aware of the full parser context, even though it leads to inconvenient results, such as a-----b being interpreted as a -- -- - b instead of a -- - -- b, even though the parser will reject the former but accept the latter.
This design principle for programming languages is often surprising to beginners, because it's so different from how humans understand natural languages; we will go out of our way to "repair" some kind of contextually appropriate meaning from even the most nonsensical sentences, and we actually rely on this in conversation.  It might help to contemplate the meta-principle that worse is better (to oversimplify, because you can get the first 90% of the work done quickly and put it out there and then iterate on the remaining 90%).

A:

Why does the C grammar allow syntactically legal, but semantically illegal declarations like int func()()?

Your question basically answers itself:
Quite simply, it's because it's a grammar's whole job to accept syntactically legal constructs.  If something is syntactically legal, but semantically meaningless or illegal, it's not the grammar's job to reject it -- it gets rejected later, during semantic analysis.
And if the question is, "Why wasn't the grammar written differently, so that semantically illegal constructs were also syntactically illegal (such that the grammar could reject them)?", the answer is that it's often a tradeoff whether to reject things during parsing or during semantic analysis.  C's declaration syntax is pretty complicated, and there's an obvious desire to make the grammar which accepts it about as complicated as, but not significantly more complicated than, it has to be.  Often, you can keep a grammar nicely simple by deferring certain checks to the semantic analysis phase.

