I'm using nginx for many years (used mostly apache before that) and would say as web servers configurations go nginx is one of the easiest to work with. I've seen complex and hard to understand nginx configs but they abused rewrite and logic which they implement was complex itself.
add_header inheritance is counterintuitive bot once you know how it works it should not be a problem. Another problematic directive is "if" - AFAIK Igor (nginx creator) designed config to be declarative but had to add "if" (imperative directive) after numerous feature requests and "if" didn't fit existing architecture well.
Try Caddy once; it’s a revelation. I have committed fairly atrocious crimes with nginx over the years, only to figure out just how much better I could have had it.
I've tried to try - yet still on Nginx as my primary web server and Apache somewhat secondary (with may be 5% for Apache and 95% for Nginx) web server of choice.
No doubts I'm not an expert in Caddy and there are some chances it has unique selling proposition, but I'm yet to find it.
My take on Caddy was - something to let your quickly-crafted-something-newshiny-loneley-dev-docker-container-to-be-available-to-the-world - sort of the same case if I do some tests (we call it MVP here) on my great-idea Flask app and I need plain reverse proxy in front of it with SSL termination, as noone except me and may be couple of Shodan bots won't see.
Yet not mentioned unclear stable releases policy for Caddy.
It's absolutely true that the nginx config has some really obtuse features, "if" probably being the best example. But just because they're there doesn't mean you have to use them, and the documentation for "if" includes ample warning about its pitfalls and openly advises against using it.
In fact, I'd argue that learning not to use them unless they're absolutely necessary is a good lesson on the importance of keeping things simple. When I was a beginner to web servers, I spent quite a few hours wrangling nginx configs trying to do things like fancy conditional redirects, removing .php extensions from pages, etc.. But over the years I've slowly learned that most of this logic belongs in application code, not in nginx, and nowadays I can set up a new nginx server in minutes because the configuration format is actually quite simple and intuitive once you understand what you really need, and what you should leave out or implement elsewhere.
Configuration files should be self-documenting.
Instead nginx taught us that if != if.