Почему в .NET нет встроенных типов данных с фиксированной точность?

Потому, что таких типов нет в процессоре. Их в любом случае придётся моделировать программно - что многократно медленнее, чем поддерживаемые процессором числовые типы. Так зачем переусложнять язык встроенными типами, которые требуются крайне редко?

Для большинства финансовых вычислений вполне достаточно целых 64-битных чисел (даже если 4 знака после запятой, диапазон будет от -900 триллионов до +900 триллионов). Для физики - вычислений с плавающей запятой.

их реализуют для каждой конкретной задачи (кому-то нужна огромная разрядность, кому-то достаточно int но с масштабом).

Микрософт, видимо, отдал BCD на откуп разработчикам сторонних библиотек. Никто ведь не мешает сделать библиотеку с ассемблерной реализацией на тех архитектурах, где есть инструкции для операций с BCD.

А в тему того, что "десятичная арифметика не нужна": некоторые факты говорят об обратном.

IBM в 2003г публиковал результаты исследования, в которых говорилось, что более половины числовых данных в коммерческих БД хранятся в десятичном формате.

Популярный тип number в Oracle - десятичный, а не бинарный. Аналогичные типы есть в Sybase (numeric), MS SQL (decimal), и они используются чаще, чем бинарные. Даже первичные ключи обычно делают на этих типах, а не на бинарных, по крайней мере, в первых двух СУБД. Каким-то образом сложилось, что максимальное количество цифр в этих типах = 38.

Старые процессорные архитектуры (например, VAX, x86) имели инструкции для операций в десятичном формате; в x86 до сих пор присутствуют инструкции для арифметики BCD и преобразования между плавающей точкой и BCD. AMD, правда, выкинул их реализацию из процессора, предлагая софтверную эмуляцию, но само это решение - экономия путём "обвеса" - вполне в духе вечно догоняющего AMD и не разделяется серьёзными производителями железа для корпоративного сегмента.

IBM, в своё время первым реализовавший поддержку BCD в мейнфреймах, до сих пор включает её в свои процессоры. В линейке Power она есть.

Fujitsu включил акселератор BCD в свой Sparc 64.

Инструкции для BCD-арифметики присутствовали в Itanium.

В архитектуре RISC-V, представленной в 2010г (т.е. это не наследие 1970-х) целевым признан программно-аппаратный подход к реализации BCD. Исследования показали, что он ускоряет операции с BCD в 1.43 - 2.87 раз по сравнению с чисто программной реализацией, при этом "облегчая" железо на 7-97% (да, такой разброс) по сравнению с реализацией BCD целиком в железе.

Что касается целых типов, то для банковской арифметики int64, конечно, не хватит, нужно же покрывать все ситуации (и вспомним 38 цифр в БД - см. выше; int64 хранит только 19 без знака или 18 со знаком). Скажем, облигации США котируются на биржах США в тиках по 1/64 доллара, что требует шести десятичных знаков после точки только для хранения конечного значения, а для промежуточных вычислений нужно больше (конечно, именно тут бинарный тип подошёл бы лучше, но кто будет специально ради тибондов его реализовывать? и потом всё равно понадобится конвертация в десятичный для денежных расчётов). Давно этим не занимался, но по-моему, в T-Bond опционах можно получить шаг в 1/128 доллара, это 7 знаков после точки. Вот int128, вероятно, хватило бы даже котирование тибондов в тугриках Зимбабве 2008г, если бы кто-то вздумал это делать. В Европе таких закидонов нет, T-Bonds на европейских биржах котируются в десятичных инкрементах (c 4-мя знаками, по-моему), но там есть индексные опционы с мультипликатором, являющимся обратной величиной цены исполнения (strike) до 6 знака после точки.

Все ли операции на бинарных типах быстрее, чем в BCD? Строго говоря, не все, и разница в цене неодинакова для разных операций. Умножение, деление на степени 10 и 5, округление до степени 10 на порядок быстрее выполняются в BCD. А при хардверной поддержке арифметики сложение, умножение и шифты бинарных и десятичных чисел незначительно отличаются по цене. Так что без профилирования нельзя сказать, что бинарный формат однозначно быстрее десятичного, и тем более - насколько быстрее в конкретном алгоритме.

.NET не включает встроенные типы данных с фиксированной запятой, поскольку .NET Framework разработан как платформа общего назначения и, следовательно, должен обеспечивать поддержку широкого спектра различных типов приложений. Типы данных с фиксированной запятой наиболее полезны для приложений, требующих высокой точности и точности, таких как финансовые и научные приложения, и поэтому не нужны для большинства приложений общего назначения. Для приложений, которым требуются типы данных с фиксированной запятой, .NET предоставляет пакет NuGet Designer с фиксированной запятой, который позволяет разработчикам определять свои собственные типы данных с фиксированной запятой.

В .NET есть структуры Decimal и BigInteger, которые могут быть использованы для работы с числами с фиксированной точностью.

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

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

Таким образом, в .NET нет встроенных типов данных с фиксированной точностью, так как это зависит от конкретных потребностей разработчика и может не быть необходимым во всех случаях. Однако, .NET предоставляет инструменты для работы с числами с фиксированной точностью, которые можно использовать при необходимости