Много маленьких запросов к REST API или один большой?

Если у вас сейчас что-то вроде этого:

GET '/posts/slug/'

{
  post: { /* ... */ }
}

GET '/posts/slug/comments/'

{
  comments: { /* ... */ }
}

GET '/posts/slug/comments/users/'

{
  users: { /* ... */ }
}

GET '/posts/slug/author/'

{
  author: { /* ... */ }
}

GET '/posts/slug/meta/'

{
  meta: { /* ... */ }
}

то логично все связанные данные объединить в один запрос:

GET '/posts/slug/'

{
  post: { /* ... */ },
  linked: {
    users: { /* ... */ },
    comments: { /* ... */ },
    meta: { /* ... */ },
  },
}

graphql это решает как бы,
Rest не единственная возможность общения клиент-сервер

Я думаю, что оба варианта имеют право на существование, они не плохие и не хорошие. Все зависит от задачи, от требований, от того как дальше вы будете развивать систему и т.д. Просто вы должны знать, что чем больше запросов - больше сетевых издержек, но зато вы сможете запрашивать с клиента только то, что вам нужно, вы можете переиспользовать существующее API в разных фичах приложения. В случае комплексной модели - фронт работает быстрее, нет необходимости "склеивать данные", как при этом выполняется более сложный запрос на бэке - это надо смотреть. То есть у каждого варианта есть свои плюсы и минусы, и какой способ выбрать зависит от конкретной вашей задачи.

Смотреть нужно, вам на фронте какая разница? Хоть 100 запросов, если сервер не против. Помните, что делать можете, как решите. Если есть проблемы с производительностью? Нет? Забейте.
Есть важные моменты, типа кэша, количества обращений и прочего. Как производите выборку на стороне сервера, делали оптимизацию запросов? Какой кэш используете? И тд

Представьте, что один клиент, условно выполняет 100 запросов на сервер

100 * 1000 клиентов.