Аналог Vuex встроен в Svelte — svelte.dev/docs#svelte_store
Svelte может себе такое позволить, так как если Вы это не используете, этого не будет в бандле

Насчет роутера, почему то в React никого не смущает, что людям нравятся разные роутеры с разной архитектурой. Vue тут скорее исключение, что есть 1 вариант и костыли вокруг него, чтоб эмулировать другие подходы к роутеру.

Загляните сюда, здесь лишь малая толика отборного, из всего того, что есть:
github.com/TheComputerM/awesome-svelte

А как доказать, что строка, которая пришла с сервера, это действительно UserName, а не что-то иное?

Проверить, что она соответствует всем ограничениям на тип UserName, если проверка успешна — я получу тип UserName, иначе получу ошибку. Другого способа получить тип UserName в программе нет, поэтому ему можно доверять. А вот типу, в который можно просто кастануть любую строку я доверять не могу, он для меня бесполезен.

const nameOf = (name: string) => name as UserName;

Вот я и говорю, что это не работает, любую строку можно просто привести к типу UserName без доказательства последнего

Как минимум языки с сильной типизацией не имеют супертипов, вроде Object в джаве и шарпе или типов принимающих в себя что-угодно, вроде any в тайпскрипте или void* в C, ну или как минимум не позволяют свободно кастовать через такой тип что угодно к чему угодно и потом падать в рантайме если кто-то где-то вдруг ошибся.

Очень многие путают статическую типизацию и сильную. А еще многие не понимают, что значит сильная типизация. Даже тут, в комментариях к этой статье видел заявление, что в Java сильная типизация…
Отсюда и мифы, что typescript от чего то там спасет. Но вот от кривых рук писателей библиотек он не спасает… Как и не делает ни малейшей попытки спасти от кривых рук пользователей библиотек у которых нет ts…

Если речь про js, то проблема не в том что оператор + перегружен, а в том, что он неяно приводит типы

Позвольте, .onclick, как и .match(..)[0] могут вполне неиллюзорно выкинуть undefined, и писал бы я на ts, обязательно пришлось бы его убеждать, что я понимаю что происходит с помощью as

Если Вы уж так уверены, что там точно нет ни одного undefined/null, то на ts добавится всего 2 символа:

Array.from(document.querySelectorAll('.button'))
    .map(a=>a.onclick!.toString().match(/https:\/\/[^']+/)![0])
    .join('\n')

Хотя гораздо безопаснее все же написать так:

import {fromNullable, andThen, map, unwrapOr} from '@lambda-fn/option';
import {pipe} from 'ramda';
Array.from(document.querySelectorAll('.button'))
    .map(a => pipe(
            andThen(fn => fromNullable(fn.toString().match(/https:\/\/[^']+/))),
            map(matched => matched[0]),
            unwrapOr('')
        )(fromNullable(a.onclick))
    )
    .filter(url => url !== '')
    .join('\n');

Потому что имена аргументов, это так же часть сигнатуры и она важна для понимания, что функция делает.
В Вашем варианте foo я понятия не имею, что за строку она от меня хочет, но стоит написать вот так:

function foo(userName: string): string;

и все стало гораздо понятнее, хотя foo по прежнему не очень удачное имя…

И да, по-нормальному было бы вообще так:

function foo(userName: UserName): string;

но убогая структурная система типов тайпскрипта не дает это выразить нормально

удалено

Весьма точное сравнение. А отсюда напрашиваются пара выводов:
1. Можно просто собрать несколько удачных решений в одном месте, хорошо так присыпать пиаром — и все, готов продукт которые будет нравиться многим.
2. Распиаренность и наличие преданных фанатов не означает, что продукт лучше других.

React и Angular — реальные инновации, они полезны экономически

Извините, а в чем инновации в React?
Писать js прямо в шаблоне? — Было до него, шаблонизатор ejs, хоть и строковый, но позволял писать в шаблоне любой js, даже обычные циклы и if'ы
Компонентный подход? — Ну в принципе он давно известен в разработке UI, и даже в вебе он уже был в angular.js, в Elm, а может и еще где
Хм, может VirtualDOM? — Ан нет, Elm был как минимум на год раньше с этой идеей. И с идеей, что компонент — это просто функция, которая возвращает вьюшку. Притом это все было весьма достойно для универской курсовой, коей являлся Elm, но уж никак не для либы агресивно впариваемой большой корпорацией.
Что-то еще? А ничего больше в самом реакт и нет собственно. Просто распиаренный шаблонизатор с поддержкой компонентов и работающий на таком костыле как VirtualDOM.

Нормальные типы к TS пишут вообще единицы, а без них полезность TS вообще стремится к нулю… Ну а тесты у нас ревьювят в первую очередь.

Удобство Vue в том что в каждый из этих этапов мы можем проникнуть и написать скомпилированный код (рендер-функцию) сами

Да, можно написать код который генерирует дерево VirtualDOM, но при этом оно все равно будет иметь этап обработки в рантайме, прежде чем попадет в реальный DOM.

В Svelte же мы ограничены исключительно декларативным подходом.

В Svelte императивный подход заключается в манипулировании нативным DOM с помощью небольших функций-хелперов из модуля svelte/internal
Никто не мешает сделать руками так:

import {
    SvelteComponent, init, noop, not_equal,
    create_component, mount_component, destroy_component,
    insert, detach, element, text
} from 'svelte/internal';

class Component1 extends SvelteComponent {
    constructor(opts) {
        super();
        let div, prop;
        init(this, opts, ($$self, $$props, $$invalidate) => {
            $$self.$set = $$updatedProps => {
                ('prop' in $$updatedProps) && $$invalidate(0, $$updatedProps.prop);
            };
	    return [$$props.prop];
        }, ctx => ({
            c() {
                prop = ctx[0];
                div = element('div');
                div.textContent = `Hello ${prop}!`;
            },
            m(target, anchor) {
                insert(target, div, anchor);
            },
            p(ctx, [updates]) {
                if(updates & 1 && prop !== ctx[0]) {
                    prop = ctx[0];
                    div.textContent = `Hello ${prop}!`;
                }
            },
            i: noop,
            o: noop,
            d(detaching) {
                detaching && detach(div);
            }
        }), not_equal, {});
    }
}

class App extends SvelteComponent {
    constructor(opts) {
        super();
        const comp = new Component1({props: {
            prop: 'world'
        }});
        init(this, opts, null, ctx => ({
            c() {
                create_component(comp.$$.fragment);
            },
            m(target, anchor) {
                mount_component(comp, target, anchor);
            },
            p: noop,
            i: noop,
            o: noop,
            d(detaching) {
                destroy_component(comp, detaching);
            }
        }), not_equal, {});
    }
}

document.addEventListener('DOMContentLoaded', () => new App({
    target: document.body
}));

Да не спорю, это совсем не

render(h) {
    return h('div', 'Hello world!');
}

но на то оно и выхлоп компилятора, работающий напрямую с нативным DOM

Просто это Вам попросту не нужно, все что обычно в vue решается самописной render функцией, в svelte гораздо проще сделать с помощью use:action

почему во фронтэнде не прижился подход с JS-as-assembly

Потому что js вполне себе человекопонятный язык. Вы спокойно можете его читать, править и даже просто писать на нем. И Вам не нужно для этого objdump или подобных утилит.
Согласитесь, никто ведь не пишет в wasm файлы напрямую, то же касается elf и exe.
Хотя признаюсь, я в свое время писал руками числодробилку на asm.js, но asm.js тоже вполне человекопонятный, да и вызвано это было скорее тем, что emscripten в то время для абсолютно аналогичной функции на C генерил в 3 раза больше кода asm.js, чем я написал руками.

в большинстве случаев это будет блок {#each} прямо в шаблоне. Да, если туда попадет не коллекция, оно упадет в тестах ну или в рантайме…