As you shall see, the spirit of this answer is that, in game programming, there is rarely a dead-on answer like A is always better than B. But let's dive a bit more into the details.
So my main question is, what would work on a near infinite procedurally generated world?
Any would work. It depends on many other characteristics of your game, for example (but not exhaustively): will it have big open areas or will it be always packed with obstacles? Do you need information about the traversal cost of terrains everywhere or nowhere at all? As you see, that question is way too general to be answered.
And what is fastest quadtrees or navmeshes?
First things first: quadtrees are not a specific path-finding search space type. They are, in your context, a spatial partitioning technique. It means, in your tile-based search space type, they allow you to group similar tiles into greater areas, to reduce the number of similar tiles.
So, whether searching trough quadtrees of nodes or navmeshes will be faster, it depends on how much reduction of the search space the quadtrees will achieve in your particualr types of maps. I.e. which will leave you with fewer nodes in the graph where path will be searched for. In practice, in my experience, it will be very rare that quadtrees will end up with fewer nodes than navmeshes, because where quadtrees offer their biggest advantage over simple tile-maps, i.e. open areas, is precisely where nvameshes excel too.
However, in the case of a procedural map where navmeshes have to be built on the fly, you have to also consider the cost of building it. That is particularly important because you will be erasing parts of the map from memory when they are out of scope and rebuilding them again when player gets closer. Which means, you will be generating and probably regenerating the path-finding maps (no matter if using tiles or navmeshes) all the time.
In that regard, quadtrees are much faster, no doubt. It will be much faster to construct the quadtree of tiles in the new map areas being generated than it will be to calculate the navmesh for such new area. That means, you have to take both things into account: the time it takes to build each solution on the fly and the time it takes to use each solution when finding paths. Both things can become a bottle-neck.
Which means that, ultimately, there is no a priori answer to that. It both depends on how the characteristics of your maps, so as always, you will have to try both and profile. Always profile! That is the only way you can be assure of what works best for your specific game.
If navmeshes are faster, are polygons better than triangles?
If you are storing only the center triangles/polygons, than polygons will give you much smaller search spaces (i.e. faster to traverse when searching for a path) than triangle-based navmeshes. However, when storing just the centers, it becomes harder to smooth the path after searching the path (like Theta* does in relation to A*).
So, often other points are stored, like the vertices of triangles/polygons and even the middle point of triangles/polygons' edges. In these cases, it becomes unclear whether polygon-based navmeshes will still give you the desired less nodes than polygon-based navmeshes. It begins to depend on the characteristics of your map again. My personal experience is that, if you are storing vertices, middle-edges and centers of the triangles/polygons, than the narrower are the walkable areas, the better the navmeshes become. Conversely, the broader these areas are, the better the polygon based become.
But in general, polygon-based nvmeshes end up giving less nodes (i.e. being faster to serach for paths). On the other hand, again, in a procedually generated map, you can't forget the cost of bulding the navmesh. And it is much faster to generate triangle-based navmeshes than polygon-based.
I would want to generate more navmesh as the world is explored
This will be particularly harder to implement with navmeshes than with tiles and quadtrees. Because than it becomes not only a problem of generating navmesh, but of updating dynamically the navmeshes that were already generated. It is feasible, but not easy to program (for instance, Unity's and Unreal's navmesh system do not come with the possibility of dynamic updates).
I am unsure how that works on a large scale where I would want to generate more navmesh as the world is explored
No matter which technique you end up choosing, you will likely end up needing to implement it hierarchically. I mean, when maps currently on screen get bigger, the better way of making it faster to find a path is to give the algorithm less area to search. Take a look at this similar question and at its answers: What is the most appropriate path-finding solution for a very large proceduraly generated environment?
