Decimals are notoriously hairy to implement and it's not obvious how they should behave when they run out of precision. Integers are almost always the better choice when the decimal is fixed, such as with currency.
(I guess it depends on what you mean by "true" decimal. If you meant BigNum, then sure.)
A lot of times, though, currency is not fixed. Stock share prices can be in fractions of a cent; per-unit cost numbers can easily have fractional cents too, just for a couple of quick examples. Sure, if you're just looking at your bank account, or itemizing actual transactions, they're going to be in whole cents only, but lots of financial calculations need more precision than this.
Having different numeric types for currency amounts (integer) and for costs or prices (floating point, whether decimal or binary) is not undesirable. Heck, it's very likely a bonus.
That sounds like a recipe for disaster. If you have fractional unit prices, and multiply by the number of units, floats can still give you errors. No, fixed decimal types definitely have their uses.
If you simply look at any of the real world implementations, you'll see it's not so easy. Rust has a few readable and educational crates that implement decimals, if you want to take a look.
That's because the binary is implemented in hardware for you; and those days you can usually (but not always) trust the hardware to do the correct thing; if you have to implement it youself (say, deterministic, side-effect free math), it's also hairy.
Decimal floating point is fine so long as you constrain the exponent such that delta between two consecutive valid numbers can never be greater than 1 (that is, there should never be any implicit trailing zeroes). .NET Decimal type is a good example.
(I guess it depends on what you mean by "true" decimal. If you meant BigNum, then sure.)