This is a good thing. Apache is a swiss-army chainsaw of last-resort, not a minimal webserver.
Apache's biggest problem is that it isn't cool and hip anymore. It's config file is too easy to understand.
Good { thing we = have; nginx; }
Phew!
You can tell nginx to reload its configuration without restarting the entire server process by running "sudo /etc/init.d/nginx reload", or on ubuntu "sudo service nginx reload".
Per directory config is extremely beneficial for static hosting / VPS, but sketchy to get the security of values just right.
In 2008, my web site saw some decent traffic, and I was stuck in a spiral of buying more and more expensive servers to keep up with the demand. Some of the media files were large, and slow downloads would tie up a thread, and corresponding chunk of memory.
I spent a long time working through the documentation that was available at the time, and I couldn't get anything to work stably with Django.
Then I found a guide for lighttpd, and was floored when the resources used by my web server dropped to single digits. Much later, I'd learn that even saturating a gigabit pipe with just html/css/image traffic ran fine.
Nginx has since replaced lighttpd, since the latter doesn't seem to be well maintained these days.
As I understand it, Apache now is capable of high performance, but once bitten twice shy. The whole thing just seemed to be a big, bloated mess to me. Like you can do everything imaginable, except what you actually want to do.
I couldn't imagine a feature that would exist to convince me to move back. I expect quite a few web developers are in the same boat.
Your criticism of the config file is nonsensical. I'd use nginx with Apache style configuration over the inverse in a heart beat - though I disagree it would be an improvement.
Yeah, mod_rewrite sure is the epitome of a readable config file syntax.
Why have one or two simple to understand "if" statements when you could have a pile of incomprehensible regexps with random one letter control flow flags?
Simple. Ha.
Apache uses tons of memory regardless of which worker model is used.
Nginx is reliable and stable, we've never had memory leaks or weird shit happen. This is why it's often uses as a front-end reverse proxy.
More often, nginx is put out in front of apache where other dependencies require it (dav svn).
EDIT:
The C source files and headers under src/usr.sbin/httpd are about 100k lines. Under src/usr.sbin/nginx you have closer to 170k lines. Of course this isn't exactly apples to apples comparison as both have optional modules and at least nginx has some OS-specific code.
In any case though, it is really hard to argue that nginx is "light, small, and fast" while httpd is a bloated swiss army chainsaw with a kitten sink...
Ik can write a program that will use 100% CPU in about 10 LOC, while there can be very well-optimized pieces of software can be thousands to millions LOC.
e.g. the Quake 3 engine is probably as well optimized as you can make it and is about 300K LOC: https://github.com/id-Software/Quake-III-Arena
I agree about highly optimized code being typically larger than the simpler alternative.
Now nginx has interesting optimizations in some places (e.g. the http parser), but if you read the code, it's not like 90% of the code in nginx is there due to optimization.
I'd like to add that from an OpenBSD perspective, excess optimizations would no doubt be considered bloat as well. One of the goals is that the code is clean, correct, and secure. I know for a fact that the developers are not going to carefully audit and maintain millions of lines of micro-optimizations. What these might get you is a tick in a hypothetical feature checklist ("performance"). But if another daemon does the job and performs well enough, then that feature is unneeded complexity, hence bloat. Not something you want to include in what aims to be the world's most secure general purpose operating system.