Yes, it is one of possible decisions but that would make the tool a bit less portable. When dealing with text logs, you can move them around as well as keep backup storages updating them with new entries.

I'm confused by this. Why can you not have udev events or the kernel API doing the same thing?

Yeah, here's a one-line udev rule to log USB removal and insertion into the journal.

> $ echo 'SUBSYSTEMS=="block", RUN+="/usr/bin/logger --tag=block-device-history -- %E{ACTION} | %E{DEVNAME} | %E{ID_MODEL_ID} | $attr{serial}"' | sudo tee /etc/udev/rules.d/10-block-device-history.rules

Activate the new rule by reloading and retrigging:

> $ udevadm control --reload-rules && sudo udevadm trigger

Then in another terminal run:

> $ sudo journalctl -f

...Insert a USB drive and see information about it printed.

journalctl supports querying with time intervals (eg, journalctl --since "2018-01-10" --until "2019-08-01 23:59").

Slightly tweaked the above, in case anyone is interested. Copy the following to /etc/udev/rules.d/10-block-device-history-rules:

> SUBSYSTEM=="block",ENV{DEVTYPE}=="disk", RUN+="/usr/bin/logger --tag=block-device-history -- '%E{ACTION} | %E{DEVNAME} | %E{ID_SERIAL}'"

Run

> $ sudo udevadm control --reload-rules && sudo udevadm trigger

> $ sudo journalctl -f SYSLOG_IDENTIFIER=block-device-history

...Then re-inserting a USB device produces output similar to the below:

> Jan 01 12:00:00 hostname block-device-history[12345]: add | /dev/sdY | TOSHIBA_TOSHIBA_USB_DRV_012345678900FF00-0:0

To customize the printed variables, have a look at:

> sudo udevadm info /dev/sdY