If you can’t take advantage of Timeshift’s BTRFS support, you’ll probably need to keep an eye on disk space regardless.
All the .deb files are installed across system directories like /usr and /etc. If you only want backups of your files, just exclude everything outside /home and your data drive. This makes it more difficult to recover from a failed upgrade Windows System Restore style (as you exclude the system components from the backups) but hopefully you’ll never need that (or will be willing to reinstall and restore from backup when failure does happen). You may also want to exclude folders like $HOME/.cache and $HOME/.var if they’re present on your system. I think Chrome puts some of its cache in $HOME/.config as well, though I’d back up most .config folders myself.
If your storage is that limited and you’re already familiar with Timeshift, you may want to consider switching to BTRFS. It’s not very friendly when it’s almost full, but compression and deduplication can save a lot of disk space, especially with tools like Timeshift. Other filesystems also offer these features, but Timeshift doesn’t make use of anything but BTRFS as far as I know.
You can convert a running ext4 system into BTRFS and even move back to ext4, but to optimise the file system there are quite a few tricks to run as well. They come down to “remove the ext4 metadata (can’t go back after that), defragment, balance, maybe defragment again” and there are tools out there that make this stuff doable though the GUI, but I wouldn’t necessarily recommend that approach I novices.
The cleanest switch would be to reinstall. Not just because of the steps above, but also to make sure the right subvolumes are set up with the right properties. This too can be done from a (mostly) running system, but it’s an absolute pain in the ass to have to do manually, especially if you’re not an expert in command line stuff.
ext4 works fine if you don’t want to deal with all of this, but you’ll have to keep an eye on things like backup sizes just a bit more often