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?
It's not really that alarming. It has some deflationary effects (which Bitcoin was designed with anyway). Worst case, let's say all Bitcoins except .00000001 (1 Satoshi) have been destroyed. Well, no problem, we just make the base unit .00000000000000000001 Bitcoin or something.
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.
BTC use fixed-point math with 64-bit unsigned integers. Precision is 8 decimal places. So at least as currently built, I believe 1 Satoshi is the smallest possible unit of Bitcoin.
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.
In a nutshell, because sometimes the point really does not (and should not) float.
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.
