This particular one is described as a way to use existing Postgres GUI tooling (DBeaver, Postico 2) with SQLite. Building a compatibility shim for existing tooling is sometimes a more efficient way to solve this class of problem than adapting the tooling to support multiple backends.
I'm not saying it's what I would've done (I have little use for GUI database tooling), but I can see why someone else might.
Postlite author here. Yes, this is exactly the reason. There's no standard for connecting to a remote SQLite database so this is simply a shim to help support existing tooling. I don't use GUI tooling either but it's the most common complaint I hear when developers try switching to SQLite.
I'm not saying it's what I would've done (I have little use for GUI database tooling), but I can see why someone else might.