It's tempting to consider using an http server in your program. But also consider wrapping your c/c++ programs in fastcgi loop and have nginx run behind it.
It removes a lot of complexity from your code.
There are good intentions with that advice but I think it's misleading. It doesn't take into account how http libraries like this one (and similar ones for C++ such as Proxygen[1] and Silicon[2]) are supposed to be used.
The intended use case is to add an embedded webserver to your executable that's communicating with friendly and internal systems. That would be things like microservices and dashboards.
You don't use those libraries to create external public-facing websites that would be under attack from hostile agents. You're correct: Do not re-invent NGINX by using the C http library.
As an example proper use case, let's say you write an internal C program to process terabytes of image files. You think it might be nice to have a visual status of its progress/errors/throughput/etc. Instead of adding a GTK GUI to the code, you use the http library to expose a "web dashboard". You can then point an employee browser on the internal network at it to see its progress. For this use case, avoiding the http library and adding NGINX into the stack makes it more complicated.
Another use case without HTML gui is exposing http endpoints for microservices. Again, it's internal communication between friendly agents.
tldr: http libraries that are compiled into executables vs NGINX are for different use cases.