в чем принципиальное отличие сигналов от любой другой штуки с подпиской на изменения (например zustand, RxJS, mobx etc..)?

Отличный вопрос. Ведь все это разные способы реализовать реактивность. В чем же отличительная особенность сигналов? Для этого разберем остальные подходы

RxJS:
Основная суть в потоках данных и управлением этим потоком. Те трансформация этих данных и перераспределения между потоками. Это отлично ложится в концепции асинхронных потоков данных и событий. В противовес сигналы сосредотачиваются не на потоках данных, а на самом состоянии и отношениях между сигналами: разделение на состояния и вычисляемые состояния. RxJS это про push-based reactivity, те при отправке значения его цель уведомить всех подписчиков о новом событии и так пойдет по всем каналам, что может значительно сказываться на перфе при наивной работе с ними, так как вычисления не отсекаются по умолчанию. Сигналы же будут сосредоточены на ОБНОВЛЕНИИ состояния и оптимизации распространения обновления: если присвоить одинаковое значение или в результате вычисляемого свойства будет получен тот же результат, то распространение изменения будет пресечено. Также сигналы чаще сосредотачиваются на Pull/PushPull системах реактивности, те инициатором вычисления и обновления служат зависимости и если никто не подписан на сигнал, то и вычислен он не будет.
Итого: Push vs Pull, концентрация над потоком данный vs концентрация на связях и состояниях

Redux / Flux:
Основная задача этого подхода создать однонаправленный поток данных c прозрачными обновлениями: State -> View -> Action -> Reducer -> Actions. По сути эта модель описывает суть этого подхода. Мы здесь не видим ни зависимых состояний(как в сигналах), ни последовательных трансформаций(как в RxJS), мы тут полностью сосредоточены над контролем над обновлением состояния в 1 точке, все остальное остается за пределами. Нет тут ни подписок на отдельные части(в RTK мы имеем селекторы, но по факту они тоже подписываются на весь стор целиком, только обновление вызывают при изменении конкретной выбранной части), ни оптимизаций тому нужны ли кому-то данные эти в сторе. Здесь тоже используется Push-based реактивность: наша задача обновить состояние в Reducer-е изолировав обновление до одной точки, а остальное ему не интересно. При этом это моносторы и работа с разделением их на отдельные независимые части требует дополнительных усилий(RTK это делает за вас во многом). Сигналы же более точечно выбирают что и как им надо и каждый сигнал это и есть сам себе стор, поэтому они независимы и могут легко создаваться и уничтожаться в рантайме, что достаточно сложно для моносторов
Итого: Push vs Pull, концентрация на прозрачности обновления данных vs концентрация на связях и состояниях

Zustand:
По сути облегченные Redux или Flux, упростили API и сделали более простым для разбиения на несколько сторов вместо моностора. В остальном это тот же Flux подход со всеми его плюсами и минусами. Тоже Push-based реактивность сосредоточенная на 1 точке для обновления состояния.

MobX:
Я не так много с ним взаимодействовал, так что могу ошибаться, но MobX вполне могу назвать сигналами: я вижу что он не делает лишних вычислений, те это точно не Push-based реактивность и отсекает излишние вычисления. В нем легко создавать реактивные значения на лету (как и сигналы) и менять взаимосвязи. Также примитивы могут создаваться отдельно (зависимые значения - computed и эффекты - autorun).
Итого: тоже сигналы (по моему мнению)

Существуют и другие концепты: Effector (вечногорячие обсерваблы), $mol_wire (каналы, которые по своей сути тоже сигналы, но со своими фишками), обычные EventEmitter-ы (но они по сути глупые версии реактивных потоков из RxJS). Но их разберем как-нибудь в другой раз