Why doesn't BTC reward miners for confirmations, too? Currently as far as I know when a miner discovers enough 0s, he
broadcasts his solution to the network in order to win the coins.
While, he broadcasts his solution (which gave him the 0s), he also
verifies some transactions.
When miner verifies transactions, the gives priority to the transaction
that pays the highest confirmation fee.
As far as I understand, when the miner verifies transactions that do not
pay any confirmation fees, the miner doesn't get any rewards for doing so.
In such a case, the miner has absolutely no reason to care to verify it.
If the miner verifies such a fee-less transaction, he does it purely
because he is just a kind person, but no monetary incentives for this act.
My question is: why doesn't the BTC protocol define the BTC reward
function as a function of the solves 0s and as a function of number of
confirmations?
Specifically, I propose this reward function:
btc_reward = ZEROS_DISCOVER_REWARD
for transaction in confirmations:
    already_has_n_confirms = get_confirms_num(transaction)
    confirm_reward_rate += L / (1 + E**(K*already_has_n_confirms)
    btc_reward += confirm_reward_rate * CONFIRM_REWARD
    btc_reward += confirmation_fee # could be zero, and miners would still
                                   # have incentives to confirm, because
                                   # the btc network still rewards by
    other means.

where L, E, K and CONFIRM_REWARD are variables that need to be
tuned to adjust BTC's inflation/deflation targets (similar to like how
ZEROS_DISCOVER_REWARD is defined).
Of course this is just a suggestion for funrction with an exponential decay
as a function of number of confirmations a transaction already has.  E.g.
transactions with no confirmations are in a more disperate situation to get
some confirmation that other transactions that have, say, 10 confirmation
salready.
This way, miners will have a monetary incentive to confirm all transactions
even those that pay no confirmation fees, which will effectively reduce
the resistance against trade in the BTC world, and make BTC even more
attractive.
At the same time, people who are in a hurry can still put
their fees to get their confirmations faster.  But at least, those who are
engaging in a low-cost economy that is sensitive to fees at least have the
liberty of having a free monetary system.
Any thoughts on why this isn't done?
I'm not 100% sure I've understood your suggestion, in part because you've used some non-standard terminology.
But it looks like this is actually two suggestions rolled into one.
The first is a mechanism to incentivize miners to include transactions which have little or no fee.
That is a bug, not a feature, for two reasons:

Including transactions in the blockchain is costly. Every transaction needs to be processed not only by every node that operates now, but every fully validating node that will ever start operating in the future. The more transactions there are, the harder it is to run a node, and the less decentralized the system is.
This is why we don't want people to have the opportunity to spam the network with transactions of low economic value (due to either negligence or malice). If someone wants to have their transaction included, they have to pay for the privilege. That's why there is a limit on the block size, and users compete with fees on the right to enter the block.
Low-value payments is what we have the Lightning Network for.

A core principle of Bitcoin is to have a known monetary policy. Every reward obtained by a miner has to come from somewhere. Either from the pre-agreed inflation schedule for Bitcoin, or from already existing coins paid by users as fees. You are suggesting that miners should be paid above and beyond the inflation schedule and the user fees. Where will the money come from?
This problem is not completely insurmountable - but it's not really a simple matter of tuning a few parameters, and it does complicate the issue.


Your suggestions also seems to hint at the possibility that fees for a transaction will not be just given to the miner who includes it in a block, but rather divided between that miner and future miners who built on that block. This is similar to what I suggested here. But this is not really effective enough to be worth the trouble.