IMO a big reason is simply because they're written in C, which greatly slows down progress due to having to write a lot more code to do the same thing as higher level languages, and having to take significantly more care about memory safety issues. Caddy and Traefik being written in Go inherently solves both those problems, in addition to being built on top of Go's fantastic http and crypto stdlib packages which does the vast majority of the heavy lifting for implementing a compliant server. The remainder is mostly the config layer and middleware/admin/compatibility pieces (oversimplifying of course) which is where we can spend all our focus, being freed from having to be concerned about protocol level stuff (for the most part).

Admittedly there are some decisions we made with Caddy v2.0 that we would like to revisit eventually with a Caddy v3.0 in some future, but we haven't gotten to the point we've felt the need to plan that, most of those issues are minor enough that they haven't been deal-breakers. (And for context, v2.0 being a rewrite and rearchitecture from v0/v1 was necessary to unlock the potential that Caddy has realized today).