What do you mean?

Here, we are only talking about pages, right? So /user/id, /post/id etc?
If that's the case, you could have a /_entity/id or even a /_entity/_slug for more flexibility (_entity It can be user or post, etc.).
If you have many different pages, such as /about, /our-team, /careers, etc., I think these pages need to have their own SEO , content, and is completely legal.

I really don't understand why this would be an issue. It will be properly organized, extensible, and not have too many abstractions (which is important in my opinion).

You can also export some of these pages as .md files via nuxt/content and import them into the page. Just like the Nuxt documentation does.

If you really need to simplify these pages, you can make the entire template dynamic and generate the markup at runtime. This might introduce some huge complexity that might not be needed (in my opinion).
Additionally, layout, slots, and render functions can also be a solution.

I'm not sure if micro frontends (sounds like a hype word to me) are actually several instances of Nuxt placed next to each other (sounds like a terrible idea if hosted under the same domain), or if it's just you The “componentization” of non-monolithic full-stack applications (the way we’ve built websites for several years).
But for me, if a project has 100 pages, it's totally fine.

Of course, hardcoding some /blog/post/1, /blog/post/2 is bad (haha), but for a large application, it's totally fine. This may cause some issues with build times etc, but that's another topic and depends more on how you generate your project.

So, yes, if your interviewer wants to dig into something beyond these methods, you need to get more details from him to understand exactly the challenges and methods that can be used.

In short: As far as I know, no framework is designed to reduce the number of pages, as that is not a problem in itself. 10k Nuxt pages won't slow down your /about in any way (if it does, the problem lies elsewhere).