1.4G of logs does seem a little large. You could glance through them (particularly error.log) for problems to fix. A server with ~8G HDD/SSD total may not be too forgiving of any problems.
There are probably logrotate details I don’t understand but I expected the logrotate role to keep only 8 rotated logs of access.log and error.log each, with maxsize 50M each.
For comparison on usr size, here are root directory sizes from a fresh test server with several WP sites installed, but each site is just default WP theme (unrealistically small uploads and assets):
$ sudo du -hsc *
16M bin
38M boot
0 dev
8.2M etc
18M home
0 initrd.img
103M lib
4.0K lib64
16K lost+found
4.0K media
4.0K mnt
4.0K opt
0 proc
17M root
5.5M run
14M sbin
4.0K snap
474M srv
954M swapfile
0 sys
4.5M tmp
1001M usr
533M var
0 vmlinuz
3.2G total
Regularly rebuilding servers in an “immutable infrastructure” approach can help keep system packages up-to-date and avoid having to work out a lot of apt-get cleanup to conserve disk space.
There are many potential implementations, but one simple example would be to have DNS for your site pointed to a DigitalOcean “floating IP.” You can rebuild a whole new server and when it looks good in your tests (e.g., using new server IP in your local /etc/hosts), just point the floating IP over to the new server. If there’s a problem, point the IP back to the old server. After the new server proves itself, maybe save an image of the old server then destroy it. Of course, the process can be made much more complex to handle different structures and priorities.