No!

This is the type of confusion that happens when people try to use the accounting system in Bitcoin Core instead of implementing their own accounting system.

Bitcoin Core will just as likely choose to use bitcoins that were previously received at an account that currently has a 0 (or even negative) balance.

Think about this like a bank.

Imagine you deposit $200 into YOUR ACCOUNT at the bank, and I deposit $500 into MY ACCOUNT at the same bank.  Now imagine that I return the next day and withdraw $200 from MY ACCOUNT.  Am I going to get those exact same bills from the bank that I gave them?  No.  The bank mixes the bills all up internally and stores them all together in a vault without any indication as to which bills were deposited into which account.  The account is just a number that is updated when the deposit is made.  After that, the actual money has NO CONNECTION to the account at all.  When I withdraw $200, I might get some of my original bills, I might get some of your original bills. It doesn't matter.  Regardless of which bills I get, MY ACCOUNT will be reduced by the amount that I withdraw.

Bitcoin Core accounts work the same way.  When you "receive at an account" the account value is increased, but the bitcoins are not in any way tied to that account.  When you "send from account", the account value is decreased, but the bitcoins themselves just come from the total bitcoins under the control of the wallet.  Some of the bitcoins sent MIGHT be the same bitcoins that were received at that account, some of the bitcoins sent MIGHT have been received at other accounts. It doesn't matter.  Regardless of which actual bitcoins are sent, the account that is being "sent from" will be reduced by the amount sent.
 

If the block that confirms the transaction is orphaned, and the transaction is not in the replacement block, then it will return to unconfirmed status.  If a competing transaction that spends the same inputs is confirmed in the replacement block (or any future block) then the original transaction will become invalid and will vanish.  In this way the original transaction can be effectively "reversed" or "cancelled".

I believe the "account" system is deprecated in Bitcoin Core.

If you want accounts, you should implement them yourself in your own external system.  The functionality of the Bitcoin Core accounting system is limited in scope, and most people make bad assumptions about how it works.

There is no maximum limit. Unless there is some arbitrary limit set by your wallet. If this is the case, simply send multiple transactions. If you don't transfer the BTC using a transaction, it will NOT be secured by the network and cryptographic security features Bitcoin provides. There is nothing to stop someone simply keeping a copy of the wallet file and spending the coins themselves. The only secure way to transfer Bitcoin to another party is by creating, signing and broadcasting a transaction and waiting for it to be confirmed.

In any case, a max limit of 100 million is fine... as there will only ever be 21 million BTC

This fully depends on the amount of requests you are going to do and the kind of your alternative setup you would be using.
Without those two factors no comparision can be made.

By "account" do you mean accounts with different HD seed & different addresses, or do you mean other addresses in the wallet.
If it's the former then doesn't support accounts and will send from the default account ""

If it's the latter it just select UTXOs and spends according to the amount being sent.

Most of them are rate limited or have a quicker update frequency for paid users. So let's imagine that you have an app that it's using a specific API to show the price of Bitcoin and there are 10k people refreshing it. You will soon get rate limited for too many requests and the API will stop giving you data. This won't happen if you have a paid API with an huge/unlimited number of requests per minute.

When he sees enough confirmations to meets his risk tolerance. Each receiver needs to decide for themselves how many confirmations they need to feel comfortable with any specific transaction.  That will depend on may conditions, such as:

• What is the risk tolerance of the receiver?
• What is the value of the transaction?
• Does the receiver have an existing trust-relationship with the sender?
• Does the receiver have valid identifying information about the sender (name, address, phone, etc)?
• Does the receiver have an alternate method to extract payment from the sender (lawsuit, credit card on file, deposit on hold, etc)?
• Did any popular node software recently release a software update?

Generally (unless the transaction is millions of dollars) 2 or 3 confirmations will be fine. In some cases 1 or 0 confirmations might be acceptable.
 

The transaction remains unconfirmed until it is included in a block in the blockchain.  A new block is added to the block chain on average every 10 minutes, but it can sometimes be much faster (even just a few seconds) or much longer (even more than an hour).  The amount of time between blocks is completely random with the average over many blocks being approximately 10 minutes.

If the transaction is included in the block, then it is confirmed when the block is added to the blockchain.  If the transaction is NOT included in the block, then it must continue to wait.

No.
When a block is orphaned, the transaction might ALSO be in the new block.  In that case, it is still confirmed.
When a block is orphaned, if the transaction is not in the new block, then it must continue to wait for confirmation.

As long as the transaction is valid, it can still be confirmed.  There is no way to stop a valid transaction from being confirmed.  The bitcoins never "return to the sender".

However, if the transaction is not yet confirmed, then it is sometimes possible for the sender to send a new transaction that spends the same bitcoins.  Since a transaction output can ONLY be spent once, it is not possible for BOTH of the transactions to confirm.  When one of them confirms, then the other will be invalid.

Obviously, one person's encryption can't affect the use of another person.
Bitcoin determines ownership through a private key. You give the wallet to another person. The other party already knows your private key and can transfer your funds.
You are now encrypting the private key. When you use it, you still need to decrypt the private key. So your encryption has absolutely no effect on other people who already know your private key.
Remember: Don't give your private key to anyone.

  then you will need to build a small bot to periodically check the balances of the receiving addresses, and then make a payment to the wallet address

A wallet, in its simplest form, is a collection of private keys. Depending on the wallet software those may be stored in a wallet file or generated on the fly (ie. only the wallet seed is stored and private keys / addresses are derived as requested). Assuming a full node, this wallet software also checks for incoming and outgoing transactions.
The Bitcoin daemon is a headless wallet, that is: Instead of a GUI for users to click on, it provides an interface for other software to talk with.

I would never run a Bitcoin wallet on a VPS. There have been cases in the past where the people running the VPS have stolen money. I'd only do it unless you're doing it with a very well known provider.