за последние года два я паттерн матчинг видел только в примерах про паттерн матчинг или в сравнениях языков -_-

В шарпе вроде достаточно часто используется if(x is Foo foo)

Тут мы кажется уже переходим на вопрос, перевешивают ли затраты на протаскивание тэга, применяемые компилятором оптимизации по прыжкам
Ну тут если только бенчмаркать остается
Я не знаю, какие в Rust оптимизации ПМ применяются
Но уверен, что они есть и на достойном уровне
Можно сделать какой-нибудь средних размеров пример с ПМ, if-ами и померить

ну это совсем частный случай

Я же уже сделал и вам выложил

А вот теперь внимание, я отрефакторил так, что бы вообще не использовать ADT а использовать простой enum (не тегированный) во втором случае
https://godbolt.org/z/7XCCvA

И if-else победил даже с оптимизациями

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

Изначально я говорил про ПМ-ы с вложенными паттернами и обилием ветвей
Между которыми компилятор может прыгать по-всякому
Например, что-то монструозное типа как на скриншоте (это кстати из кода компилятора PCF)
А в Вашем примере всего одна цель, и всего две ветви, понятно что в бинарнике будет несколько последовательных сравнений, да еще это тэг, тут не развернешься с:

Про OCaml (на котором этот код) я точно знаю, что ПМ здесь будет работать быстрее, но про Rust я к сожалению ничего сказать не могу

Во-первых я не знаю Rust (никак руки не дойдут)
Во-вторых я уж точно не знаю его компилятора и какие там есть оптимизации

Пока я сдаюсь, но когда у меня будет время, я найду нормальный пример и посмотрю, что Rust умеет

не две ветыи, а три и это осознанно, две бы действительно выражались в очень тривиальный случай

А вот теперь внимание, я отрефакторил так, что бы вообще не использовать ADT а использовать простой enum (не тегированный) во втором случае
https://godbolt.org/z/7XCCvA

И if-else победил даже с оптимизациями

Вот у меня реальный пример возможностей динамического PM — преобразование в Ror.

ror = rule(
  alt(
    BitOr(Shl(X, i32(N)), Shr(X, i32(M))),
    BitOr(Shr(X, i32(M)), Shl(X, i32(N))),
  ),
  guard(lambda e: e.M == 32 - e.N),
  to(lambda e: Ror(e.X, i32(32 - e.N)))
)

и что здесь не может быть статическим? простите, не знаю этот язык

и что здесь не может быть статическим? простите, не знаю этот язык

Я был призван на холивар по pattern-matching-у с:

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

import math.{Pi, E}

...
number match {
  case Pi => ...
  ...

2) Используя bactick-экранирование

val pi = Pi
E match {
  case `pi` => // not this
  case  _   => // this
}

3) Если константа является полем, можно указать путь

number match {
  case this.pi => ....
}

Выглядит довольно просто

Во-вторых, лично я, если честно, в принципе не вижу в этом никакой проблемы
А вот в том, что в Kotlin-е нет pattern-matching-а, вижу с:
Тут дело даже не во вкусах или парадигме
Конструкция сопоставления с образцом
1) Очень выразительна и легко читаема
2) Компилируется значительно эффективнее, чем аналогичные if-else разборы
3) Повышает безопасность программ благодаря exhaustiveness checking
4) К счастью, или сожалению, но для тех же скалистов, например, сопоставление с образцом стало настолько привычной и необходимой операцией, что в язык без этого они не пойдут. И многие новички могут предпочесть Скалу Котлину из подобных соображений. Поймите меня неправильно, я ни в коем случае не разжигаю холивар между сообществами, но с моей точки зрения, не включая в язык подобные инструменты, Вы сознательно ограниваете серьезную часть аудитории, причем какую — в Скалу идут самые дотошные и принципиальные разработчики. С одной стороны, там поэтому жесть как токсично, но с другой, сторонних библиотек несметное множество и их уровень высочайший. И вот по моему мнению это серьезный пункт, угрожающий мечте об одном универсальном языке программирования. Люди по-прежнему будут идти в Скалу, считая ее обладающей более мощными средствами, а Котлин рискует так и остаться языком для Андроида, ака Swift сейчас для IOS.
5) А есть альтернативы? У паттерн-матчинга изъянов множество, но они все известны. И в выборе между ним, и вообще без него, большинство все-таки предпочитает первое (ну судить хоть по тенденции последних лет — Java, C#, C++, Swift все в том или ином объеме движутся в эту сторону).