wearemieta

Есть ли какие-нибудь проекты.сайты или приложения которые написанны на ванильном JS'e.

Не поверите, но все сайты, которые используют js написаны именно на ванильном js. Вы поймете это, когда прочитаете мой ответ до конца.

Почему для Javascript'a используется обильное кол-во библиотек/фреймворков и расширений вроде TypeScript

Давайте поймем что такое фреймворк, библиотека, расширение. Вы пишете код. Скорее всего, в разных частях и файлах вашей программы вы часто выполняете одно и тоже действие, например, делаете все буквы в слове ПРОПИСНЫМИ. Вот так на 'ванильном JS' может выглядеть ваша функция:

function wordToUppercase(word) {
  return word.toUppercase()
}

Чище некуда, так ведь? Теперь можно копировать этот кусочек в любую часть кода где он нужен. Но что если нам нужно слегка поменять эту функцию, например, так:

function wordToUppercase(word) {
  if (word.length > 3) {
    return word.toUppercase()
  }
}

И снова чистый js. Теперь снова можно копировать! Но если мы хотим в одном случае считать длину слова, а в другом нет? Скопируем два раза и изменим в одном месте? А если мест много?

Возникла проблема. Нужно решение. Одно из решений может быть таким: вынесем эту функцию в отдельный файл, будем обращаться к ней из других файлов по мере необходимости.

Что же произошло? Мы нашли подходящее решение для нашей проблемы и вынесли его в отдельный кусочек кода. Так что же все-таки фреймворк, библиотека, расширение?

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

Библиоте́ка (от англ. library) в программировании — сборник подпрограмм или объектов, используемых для разработки программного обеспечения (ПО).

Теперь мы можем легко реиспользовать наши наработки в других похожих программах.
Говоря абстрактным языком, библиотека — набор решений для часто встречающихся проблем.

Опять же, абстрактно, фреймворк — набор решений для часто встречающихся проблем. Только он решает другие проблемы, нежели библиотека. Проблемы структурирования.

Структу́ра (от лат. structūra «строение», «устройство», «связь или расположение составных частей»):

Почему для Javascript'a используется обильное кол-во библиотек/фреймворков и расширений вроде TypeScript

Люди обильно писали код на js. Сталкиваясь с определенными проблемами они находили решения. Эти решения они стали выделять в библиотеки, фреймворки и расширения, которые являются ничем иным как определенными способами решения определенных проблем/задач.

Поэтому, каждый раз, перед написанием чего-то нового вы стоите перед выбором: придумывать решение своим задачам самостоятельно, либо использовать готовые решения. Вот и все.

может ли уменьшится в них надобность с выходом Es-6/7 и дальнейших спецификаций?

Спецификации точно таким же образом используются для решения определенных задач. Если задачи вашего приложения можно решить с помощью спецификаций, то надобность вашему приложению
в других инструментах решения уменьшится.

Сможете теперь ответить, почему все сайты, которые используют js написаны именно на ванильном js?

А почему вам нужно это делать именно в роутере? Вы пишите:

но если у меня куча компонентов

то есть, если ваша функция использует компонент, то он может быть еще не отрендерен в момент вызова вашей функции.

Гораздо удобнее вызывать вашу функцию в процессе жизненного цикла компонентов:
Lifecycle-Diagram
Vue component lifecycle

Например, вот так:

export default {
  mounted() {
     GM.UserPage.GetUserInfo(this.$route.params.id)
  }
}

В этом случае мы точно уверены, что компонент отрендерился. В документации к роутеру используется подобный подход: Vue Router Data Fetching