There's a decent bit of optimizations that sqlite can do by virtue of effectively being single-writer that postgres can't without compromising a lot of other workloads. That's e.g. one of (but not the only) the contributing factors to why the per-row overhead in sqlite is smaller than in PG. And of course something like PG won't be embeddable into the address space of an application, which invariably leads to higher latency (even if it still can be low).
WRT "embeddable postgres":
Postgres relies on having multiple processes that collaborate on making database access fast. And it requires there to be only a single instance of postgres that can access the data. There's some inherent increase in difficulty of embedding something like that compared to something with sqlite's architecture.
Until recently PG didn't have a way to provide non-tcp access on windows, which made embedding on windows a bit more problematic. But since Win 10 unix domain sockets are available on windows, so things have gotten better.
I'd guess that after that the fact that a postgres installation consists out of many files, instead of a shared library or two, is the biggest difficulty. Those files are relocatable at least, but it's still far less convenient.
I don't know how much of a relevant factor the layout of the "data directory" is - for some database embedding scenarios it sure is convenient to only have to deal with a file or two. But moving a directory around isn't that much harder...
My guess is that somebody with interest could improve the situation measurably within a reasonable timeframe...