As some of the comments note, it's not Debian's job to decide which kernel images you need or don't need. Debian is doing the correct action, preserving your kernel images when it installs new ones, which allows you to boot into a previous version if something went wrong with the newer version. As frostschutz noted in his comment, Arch Linux has the opposite problem, of removing the old kernel image when installing a new one, which is in my experience highly undesirable behavior, though usually it works fine, but not always, particularly when there is a regression in the newer kernel.
This behavior can somewhat vary based on what you want your system to do or not do depending on how you configure it, how you use apt, and what method you use to install new kernels, but I would always, and have always, chosen to keep my previous kernels installed until I remove them explicitly once I've determined that the newer ones work fine, as part of maintaining the system.
However, I believe you are probably using the kernel metapackage on a stable Debian, which is slightly different, I believe that adds a new item to the grub boot list every time it installs an upgraded kernel (like initrd.img-4.15.0-191 to initrd.img-4.15.0-192). So the kernels are packages that are still installed, until you uninstall them. I'd say it's safe to say that Debian expects the system administrator to be aware of simple things like making sure partitions are large enough to do their jobs longer term, and to do scheduled cleanups if partition sizes are an issue.
However, in a sense, this is all totally beside the point, each new image takes up, once installed, maybe 150 MiB or so of space, so the actual issue here is simply that your / is just too small. Or if you are using a separate /boot partition, that's too small. Depends on your setup, you didn't give an relevant details, but that's the main issue.
You can generally use
apt autoremove to remove old packages not used anymore, so that might be the simplest solution for you, to just script in that to run daily or weekly or whatever makes sense.
Checking my /boot, the initrd.img, System.map, and vmlinux- files are about 22 MiB for each set, a remote server is about 55 MiB for each set of 3 files, which is not very big, which would suggest your /boot is simply way too small, but that depends on what your / and or /boot look like, and if it's a separate partition.
If you don't have any control over your environment, or if you can't resize the partitions to be something more useful long term,
apt autoremove run nightly is probably your best bet, after the automated upgrade runs. Or
apt-get autoremove if the Debian is older.
Checking a few remote servers, I noticed a tendency to have the current kernel, and 2 previous ones, but I don't know what does that cleanup action, if it's a setting or configuration you can make with apt, or if it's a scripted solution that just runs nightly. It's definitely not done manually.
I also agree with frostschutz when he notes that online directions for sizing /boot if separate partition suggest tiny sizes that make no sense when you have often terabytes of storage, but you didn't list any specs of the system so that's just guessing. In general you want to post relevant information to your issue when you post a question since otherwise people have to guess.
If you are planning on running the system long term, then you want at least 2x the used capacity in /, 3 to 4x is better, since / contents always get bigger over time. And if separate /boot, then just do the math of how much each kernel will take up, assume each iteration will get about 10% bigger give or take over time, then how many kernels you want to keep active, and that would determine how big your /boot should be if separate. With overhead added on to be on the safe side.
Also, you want to run apt-get clean after each update, of course, otherwise /var/cache/apt fills up with old packages.