The (config) database is supposed to be located on the machine that has access, so if you can get the database, you probably have everything (except the passwords).
So, yes, IMO only the passwords should be protected. The reason it is not fixed is that there is no clear marking for which fields can contain passwords. But starting with the connection info and backup passphrases would be a great start.
Since most Linux distros ship SQLite without the weak RC4 cipher, there is no protection on Linux by default. I think it would be a better solution to simply encrypt the fields in the database (done by the application) instead of using poor encryption on the whole file.
This would increase the cryptographic strength, increase system compatibility, simplify working with the DB in a UI tool, and keep all OS’es the same.
It is a bit like a physical keyring, it really keeps everything together, but also makes it likely that you will loose all keys at once.
The benefit from using the system keychain is that it is the best protection the system has to offer for storing secrets encrypted at rest. Generally the keychain will use whatever HW features are present to prevent leaking the master key, and already provides a method for unlocking the key. At least on MacOS there is a check for which processes can access a certain secret, which makes it significantly more secure than anything that can be done without OS support.
Sounds amazing, that http server that is currently being used is ridiculously outdated; it is a small wonder that it still works with modern browsers.