Now this shows, that in 0.20 seconds, 110 database queries are executed.  Multiply by 5 to get queries per second.  550 queries per second is definitely not "low traffic" database stuff (expecially for a CLI utility!)

The locking problem happens because, as you have stated, select queries can happen concurrently, and in fact, if you look at the test.txt i just posted, most all of the queries in the status script are select queries.
The problem is that sqlite requires exclusivity when doing update/insert statements (such as when you add/edit/delete something from the control screen or the update patch system alters the schema).  When trying one of these insert/update statements and there is currently a select statement querying the database, the insert/update can't get exclusivity, and errors out.  And as you can see, with 500+ queries per second, if you try an insert/update statement, the chances of a select statement happening from other code is at that very moment is very high (though this has been purely timing based, as the status loop currently doesn't run full-out with a built-in delay)

In the end though, it seems like the newer approach is working like it should be, so all is good!