I agree, but also don't underestimate the problems and risks in real systems that keep changing.
I've shipped some data in a JSON file bundled with an application, because it didn't change a lot, and we had frequent (biweekly) releases anyway. I mistakenly assumed those two things would always be true.
As time went on, the frequency of necessary changes increased but our overall products release cadence got worse and worse (many months) as the product grew. So customers had continually outdated data.
An additional problem I didn't expect is that since we wanted to get customers the latest data (because the next release was so far out), we had to update the data set as close to release as possible. So always a change at the last minute, which is already a busy time and means it's not really tested well. And also it was extra toil; we had a script for data generation but it still needed a manual run and pull request. In the time I spent running this I could have easily written an API based version several times.
Another problem was that this change had to be made for every release, including bugfix ones. This caused frequent discussion (do we need this?), was forgotten a few times, and caused merge conflicts later which were annoying because in this case the proper way to merge was to ignore both ancestors and rerun the script, which people weren't used to.
Of course I rewrote it eventually (after convincing PM that I need time for this supposedly long done feature again), but then I had to deal with the extra problem of customers who had local customer specific modifications of the file (because that was the workaround our support staff came up with as a way to deal with the outdatedness).
Thankfully, a problem I did not habe was binary data in git. The commits were ugly but at least still got ok diffs (once we sorted the JSON file properly). But you mentioned SQLite, which is not a good match for git. Of course one can work around it by merging the raw SQL, but still, yet another pitfall.