My opinion of the article is neutral with a mostly negative lean.
I don’t think it’s particularly interesting. It is not technical. It is lazily researched. It doesn’t really say much that isn’t already well-known or easily guessable. I also think its claims are dubious and its overal conclusion isn’t helpful.
Scrutiny:
Caddy provides the following directives:
file_server: implements a static file serverphp_fastcgi: proxies requests to a PHP FastCGIreverse_proxy: directs incoming traffic to one or more backends with load balancing, health checks, and automatic retries
That’s like 1/10 of the Caddyfile directives, but OK.
In terms of performance, Caddy has been shown to be competitive with Apache but behind Nginx both in terms of requests handled per second and stability under load.
Using 17-month-old benchmarks, which I still have qualms with as I’ve run Caddy to be faster than nginx. This was 6 years ago, and frankly it has only improved since then, but benchmarking web servers like this is useless for general consumption.
(And Caddy is basically as performant as any other Go server, which is not slow.)
If Nginx is being used for performance optimization, it may not be possible to replace it with Caddy without observing some degradation in performance.
I could say the inverse too. And if Caddy’s 50K+ or 100K+ req/sec aren’t fast enough for you, you’ve got bigger problems. Your bottleneck is not your web server, and I’ll argue that web server performance doesn’t matter these days for most sites. It’s an over-hyped useless metric.
Another possible downside to Caddy is that it currently has a small market share, possibly limiting resources for education and troubleshooting:
Sure, we all know that nginx is used on most sites and that Caddy is not. These stats are probably derived from scanning Server headers, which many Caddy users strip for some unknown reason, or at least a reason I don’t fully understand.
In this article, we discussed some of the key traits of Caddy, Apache, and Nginx to help you choose the web server that best suits your project’s needs.
The article didn’t talk about needs, only performance and configuration, and not nearly technically or rigorously enough to be useful. Sloppy at best.
If your primary concern is performance, or you plan to serve a large amount of static content, Nginx is likely your best option.
Should read: “If your primary concern is performance, you wouldn’t be reading this article, because you’d be busy profiling and tuning your bottlenecks, not racing web servers. If you plan to serve a large amount of static content on sites that scale your HTTPS gracefully and reliably, Caddy is your only option.”
While Caddy is easy to configure and performant for most use cases, if you need flexibility and customization, Apache is your best bet.
This is bull–, ahem 
I mean, this is unsubstantiated.
Keep in mind that you can also combine any two web servers for a great result. For example, you can serve static files with Nginx and process dynamic requests with Apache or Caddy. Thanks for reading, and happy coding!
Citation needed. This is a bit dismissive, isn’t it? You should not combine two web servers for a “great result” unless you absolutely need to. The example here doesn’t make any sense. More moving parts will only complicate and slow down your setup, for instance:
https://twitter.com/uninen/status/1442891193126293506
https://twitter.com/webology/status/1442894948458631174
https://twitter.com/_stoakes/status/1425700401022705669
https://twitter.com/_stoakes/status/1425869103265419279
I think the article is just marketing fluff to gain keywords and high results in the SERPs.