Databases have been generating machine code for things like sorts since the 60s. JIT code for queries is a very old approach.

Databases are a lot more interesting than they appear on the outside. They combine the disciplines of compilers (parsing, typing, optimization, codegen), operating systems (caching and memory management, concurrency, file systems) and distributed computing (replication, distributed transactions) all in one project.

MSSQL has been compiling plans to bytecode, but not in a manner which can be directly or JIT compiled to machine code. There is a big difference in compilation & runtime performance with an LLVM-based approach, which can be directly or JIT compiled.

That said, stale plans and parameter sniffing are problems with any system that optimizes and caches plans, regardless of whether the cached plans are compiled to bytecode or machine code (including Oracle, etc.).

The exception is Hekaton (MSSQL's in-memory database), which transpiles entire stored procedures to C (http://www.vldb.org/pvldb/vol7/p1095-nagel.pdf). This approach is very much optimized for in-memory OLTP, which is a different use case than Postgres's.

I do not think there should be any issues since PostgreSQL already handles invalidation of plans for when indexes and tables change. Adding JIT does not add any new hazard here.