It does, yes. The best architecture when using LMDB is to have a single writer thread, and many independent reader threads.
That said, it is nice to be able to run the occasional separate process to do some maintenance task on the database (e.g. to do some writes), and the global lock comes in handy then.
The main reason a single write thread design isn't a problem is you can do a million or more separate, fully transactional and isolated write transactions per second on a single core with LMDB. Writes are simply not the bottleneck.
You can't get anywhere near that kind of write performance with a fully transactional and concurrent write system like CockroachDB, not even with 100x the hardware. However, some of the eventually consistent databases, like ScyllaDB, can scale up to more total writes per second (but of course you give up the transactions, and the consistency).
The actual issue I have with using LMDB in this way is keeping it fed! My code is now written in C++, I'm using Aeron for high-performance messaging and Cap'n Proto for messages (eliminates serialization/deserialization) as well as Cap'n Proto for storing objects inside LMDB. I'm nowhere near LMDB's write thread being the bottleneck, and I'll only get close to it once I'm on a 20Gbit/sec machine.
IMO a properly designed system will always and everywhere be bandwidth constrained, not CPU or "architecture" constrained. (Put another way, everyone has access to supercomputers these days, we just use them poorly most of the time.)