.htaccess doesn't have to affect performance; this is more of a historical artifact. With an HTTP server expecting a read-only site root, you could only read every .htaccess once, when you replaced the site root filesystem with a new version. A user could still see a read-write filesystem, only with a "save" button (command, etc.) that created and mounted a new read-only site root.
While it is a performance and security burden, people reject .htaccess is too readily. It has enabled users who aren't quite programmers to assemble sites out of web applications and components that live in different subdirectories. It has clear value. (Not that I think nginx should implement it.)
I think the bigger issue is that the use case .htaccess was designed for (multiple users sharing a single physical server) just isn't really a thing anymore AFAIK. If you're just managing rules in your own container somewhere, there's no sense keeping the logic in multiple places.
> With an HTTP server expecting a read-only site root, you could only read every .htaccess once, when you replaced the site root filesystem with a new version
In that case you would still need some way to trigger a reload of the htaccess, right?
If so, is there a usability difference to just including nginx configs on the same locations?