Some parameters might have one or two more words to type, but the growth in flexibility is enormous, and we felt it was worth the tradeoff. You can see a comparison here: https://caddyserver.com/docs/v2-upgrade#caddyfile
We also think slightly more verbosity in the v2 Caddyfile is actually a good thing. Aside from more flexibility, it makes it a little clearer what's going on, and concerns are better separated.
For example, the reverse proxy is no longer in the business of rewriting requests: there are other directives for that.
In fact, we completely got rid of "rewrite hacks" that involved appending path components to the URI so they could be routed, then needing to strip those before proxying.
Request matching is very powerful in Caddy 2: you can still easily match on paths in-line with your handler directives, but you can also match on any other part of the request (client IP, query string, regular expressions, etc) with an intuitive @-block syntax: https://caddyserver.com/docs/caddyfile/matchers
Anyway, I think you'll feel right at home with it after a while. I've been using it for months now and it's so simple overall.
(I also use the JSON config directly on a couple of my servers, where the behavior I need to express is way more elegant and concise than in the Caddyfile.)
Thanks for the response! Looking forward to upgrade my stuff. Is there a reason why you decided to introduce an entirely new configuration method via JSON?
Basically, it is highly interoperable and allows us to build config adapters on top of it, so you don't have to use JSON if you really don't want to. Most people use the Caddyfile. You can use YAML or TOML or CUE if you prefer those. Or heck, you can use your nginx config: https://github.com/caddyserver/nginx-adapter
