is it alarming at all that the # of redeemable bitcoins are provenly monotonically decreasing after some period of time? I guess if there is a lower limit it shouldn't matter?
As far as I know, the only reason 21,000,000*100,000,000 units was chosen was to fit comfortably in the 52-bit mantissa of a 64-bit IEEE 754 floating point number.
Edit: Apparently I just made that up... But it makes sense! Edit 2: Apparently some other devs believe this is the case as well.
There's talk about it being possible to move the decimal point with a protocol update, but I'm not sure about how the logistics of that would work, or just how far it's possible to move it.
The main reason for choosing variable-precision numbers for general-purpose computing is that they have a very wide dynamic range that can adjust automatically, which makes them easier to use in more situations. In financial applications, that advantage doesn't really apply; banks don't often encounter situations where customers are worried about a ten thousandth of a cent, and they never encounter situations where it's suddenly OK to only track a transaction with dollar-level precision.
Meanwhile there are some risks to using arbitrary-precision math too. If BTC used floats, then that might result in it being vulnerable to attacks that are able to take advantage of rounding errors in floating-point math. If BTC used infinite-precision decimals, then that might result in it being vulnerable to attacks that work by creating ridiculously high-precision numbers that implementations have a hard time dealing with.
The Bitcoin code itself actually frequently uses decimal64 as well as uint64_t.