I was hoping for a C API specifically to use LOVE with a statically typed language, but because C++'s ABI is unstable writing a C wrapper is about the only way for the engine to be bound to other programming languages besides Lua. Also everything needed to quickly make a game is already included in LOVE provided the correct libraries are available in the system, so it's quite convenient.
But raylib sounds pretty simple to use if you want a library-driven approach, and the WASM support is interesting. There was at one point a project that ported LOVE to asm.js but it's since went unmaintained. I was actually able to run one of my >100MB projects on it, but it was pretty unstable and I soon ran into asset size limitations.
Love does work through wasm in the pure C++ approach, have been using it on a project for a bit now. It's definitely better that way vs. also using Lua since you can't use LuaJIT and vanilla Lua running in wasm esp. with a GC isn't geat perf-wise.
Agreed re: C API -- would definitely need a wrapper there. The C++ API is also a bit less ergonomic in some ways than the Lua one (particularly how images are initialized) but also more in others (type checking and autocomplete is great). Lovr (topic of this post) uses LuaJIT's C FFI actually with a C API internally so it's more in that direction, FWIW.
What does "library-driven approach" mean in raylib's case and how is it different from Love's approach? In both cases I just have a CMake project that builds my application to either a native executable (including mobile in Love) or web, with all dependencies vendored, calling functions and using types from either API.
I do think raylib's C API fits this well and with the least impedance mismatch, having used all of them -- Love in Lua, Love in C++ and raylib in C -- extensively. eg. you can directly manage and render vertex buffers in raylib and go down to the 'rlgl' level, in constrast I found Love's default image rendering to have perf issues in web (it uses buffer orphaning) and I had to do something more manual with Love's meshes.
But raylib sounds pretty simple to use if you want a library-driven approach, and the WASM support is interesting. There was at one point a project that ported LOVE to asm.js but it's since went unmaintained. I was actually able to run one of my >100MB projects on it, but it was pretty unstable and I soon ran into asset size limitations.