The reason seems to be mostly historical.

Prior to the 1989 ANSI C standard, C did not have prototypes. Parameters of type int could be defined implicitly; parameters of types other than int had to be defined explicitly, before the opening {.

For example, where in modern C we might write:

double sum(double x, double y) {
    return x + y;
}

in pre-ANSI (K&R) C we had to write:

double sum(x, y)
double x;
double y;
{
    return x + y;
}

The body of the function might begin with a declaration of a local variable:

double sum(x, y)
double x;
double y;
{
    double z;
    /* ... */
}

The opening { was needed to separate the parameter definitions from the body of the function, and the closing } was needed to match the opening {.

(This syntax is still allowed, but obsolescent, in modern C; it's not allowed in C++.)

When prototypes were added to the language, there was no particular reason to permit omitting the { and } in function definitions.

The trivial answer is that that's what the language grammar requires. The syntax for a function-definition is:

declaration-specifiers declarator declaration-list_opt compound-statement

where a compound-statement consists of {, followed by 0 or more declarations and statements, followed by }. This is the only syntax production that requires a compound-statement; there are plenty of others that merely require a statement.

Interestingly, in C's predecessor language, called B (documented here), the syntax of a function definition was:

name ( arguments ) statement

The statement was usually a compound statement (a block delimited by { and }), but it wasn't required to be. B did not require, or even allow, arguments and variables to have their types specified, so there was no need to have a particular syntax to separate the parenthesized argument list from the body of the function. In the earliest C reference I can find (this one, from 1974), the syntax of a function definition had been changed to require a compound statement, probably to accommodate the addition of parameter declarations.

If it was allowed, there would be no difference between a function declaration:

void a();

and a function definition for a function doing nothing:

void a()
  ;

It would add more problems than gain for sure.

I think that the problem is that it is difficult to distinguish this construction

int giveMeFive()
return 5;

and this construction

int giveMeFive() //;
                 ^^^
return 5;

That is whether the programmer made a typo.

At present the compiler issues an error. But what to do if such a function definition will be allowed? This will make the program much less clear.

In fact it could be used like a simplified inline function

T function( parameter-list ) return expression;

However placing a semicolon between the function header and its body

T function( parameter-list ) ; return expression;

changes the symantic and makes the code unclear.

The difference for example with a while statement is that a semicolon after while statement like this

while( condition );

does not change the definition of the construction. In any case it is the while statement.

However relative to the function definition the situation is different.