I cannot speak for them, but lets not forget that the backend threading pool implemented by actors is shared and the developers will often use them for other tasks like UI compositing for instance.
If you have a scenario where you know that it will be used only for file IO, lets say, that you implement a backend server that is specialized in doing SQlite queries, than there will be no issues.
The problem is that if this is a driver offering of a SQlite, this will run in the same process the user will use the actors for other tasks, often ones that need low latency, like UI compositing and audio for instance. In that particular case the time each IO task take to complete will become visible giving it will affect the performance of your low latency tasks.
If a handle to a SQlite have the proper locks and can be use by multiple threads, even then you would want to have a custom thread pool with "frontend" and "backend" threads that are specialized in long running tasks. With that configuration you can dispatch the IO to the backend threads without bothering the people that use your driver with unwanted lags in their final applications.
If you are not sure that the handle can work in multi-threaded mode, or you just want a more safe environment, than the best you can do is use a single-thread mode where you know only a particular thread will access your handle and from the perspective of that handle it is working in a synchronous mode, while you still can offer a multi-threaded environment from the point of view of the user, with multiple tasks consuming from the IO producer which runs is a isolated and safer environment.
With that configuration you can also use something like LMDB safely which as far as i know, unlike SQlite its not safe to be accessed by multiple threads directly.