That is my experience, indeed. It does not have to apply to your particular domain problems, though. I can imagine requirements that cannot be fulfilled with doubles at all and I can image the requirements that are tenuous and error-prone to implement without BigDecimal, even if possible, so using BigDecial would be a much better choice. Enigineering is always a tradeoff. There is nothing wrong in using BigDecimals to solve the problems you have at hand, since it is specifically desinged to make it conveninent working with decimals.

Kotlin does support BigDecimal math operators in its standard library for a reason of making even more convenient to use than in Java. This support will likely to be only improved in the future. It does not change the fact that Kotlin is a general-purpose language and it has to support various types of software.

What is exactly wrong with my statement that you are citing it here? Do you not agree that BigDecimal is a niche library?