Why is session defined on kernel level? Is it introduced exclusively for tty/job control?

Please note that "session" is an overloaded term and without context is not very meaningful.

In this case, you are specifically talking about a job control session, implemented with the getsid/setsid system calls. As these are system calls (not just library calls), they are implemented in the kernel.

The job control session is implemented in the kernel, it can only be implemented in the shell using these system calls and the tty job control, controlling terminal designation, and process group functions, which are all tied together.

Note that when a job is suspended, the entire session is suspended. The session is part of the job control system. The controlling terminal also is part of job control; in order for ctrl-z to suspend a program, it must be the foreground process on the controlling terminal for the process.

I think what you are looking for is the dividing line between where the kernel implements an API and where a user process (like the shell) uses that API rather than implementing it directly. Frequently, the dividing line is set by security concerns, or because existing API was already in the kernel and when related functionality was added, it was also added to the kernel.

Sometimes when you look at an API like this, you might think "why wasn't this implemented in the shell instead of the kernel" when the answer is that the shell implements it by calling the kernel API. Remember, the shell is just a user process; it is not special, it does not have extra privileges that other user processes don't have. This makes it easy to implement new shells, and it doesn't require any permissions to write or run a new one.

You ask why the controlling terminal and process sessions are implemented in the kernel instead of in the shell? It turns out, job control is very complicated and beyond what the shell can do, and the shell implementation leans on functionality provided by the kernel, and these features are implemented to support job control. This is their primary purpose, and I don't believe any higher purpose was in mind when it was designed.

Asking if this is intended to be used by anything else is unanswerable, because the API is there and anything can use it for any purpose. For instance, I can write a program like

ps -eO sid | awk '$1==$2' 

which would print out all session leaders. Does that count as "a higher purpose"? This is a kernel API available to all user programs. Any user program can use it for any purpose. It is not the purpose of a kernel API to designate a purpose, it's just there to provide the resources.

Line control (and so part of terminal control) is done in kernel, and one part of line control is to suspend process if a buffer (outbound) is full, until it get low to a certain level. This was done also on dumb-terminals.

Which process should you suspend? Probably not the "login" process kernel started, but you cannot suspend all user processes (maybe the user is connected also from a different port or a local screen). So you get the session group and the way to detach it (e.g. for daemons).

The shell has not much control on the buffers and the line (serial line, internet), so kernel seemed a good place. And it works for all kind of shells. Note: you can connect to a server without a shell (BBS, info services, think a lot of telnet services). So kernel solution is general and it is necessary (and quick) to block processes filling output buffers.

Alternative? Still the kernel must send the SIGHANG to the shell, but which process is the foreground shell? OK: probably it will send to all group, but still: you must know the group.

Think a "write" which overfill the buffer (e.g. with a shell redirection): so in case of overfilled buffer, kernel must send a fail as return to write, the shell should handle the transitional fail and the session, wait until buffer is ok and try again the missing part of write.

Note: I looked only on one part. Probably there were some other reasons (on the to factions), and someone had to do a choice. But we can all agree that the split between kernel and userspace on such part (and terminal handling) seems very arbitrary and for sure not logical (putting some control on both sides).