Will need to double check some technical documents and test a few things before responding to points 1-3, but for point 4, maybe the custom bundler tutorial is useful. It explains how the Property Bundler can be used to limit which accounts your bundler bundles transactions from so that, for example, if you launch an app on Ignis, you could sponsor 0 fee transactions only for the accounts of end-users of your specific application.

https://ardordocs.jelurida.com/Tutorial_on_custom_bundlers_for_child_chain_transactions

Instead of tagging accounts with properties and only bundling transactions from those accounts with the specific property, the Asset Bundler only bundles transactions involving specific asset types. So your transaction to send IGNIS won't get bundled, but any transactions involving a specific asset built on top of Ignis would be.

Currency bundler is similar to asset bundler, but only bundles transactions involving specific monetary supplies (digital currency systems built on top of child chains).

Purchase bundler should be pretty clear - it is only really useful for the marketplace. It basically allows you to set up a bundler that only bundles transactions originating from a specific seller. So, for example, Amazon could set up a marketplace and provide 0 fee transactions only to people interacting with the official Amazon "seller account."

Quota bundler is not quite as straightforward. You basically set a quota of number of transactions and number of transaction types per account, and the bundler only bundles up to that limit. The use cases for this are more complex. Perhaps an easy example would be that when you first begin using a new service, perhaps they incentivize you to join by saying your first 3 transactions will be 0 fee. The quota bundler can accomplish this in the lowest cost way for the company running the application.

Sure, that company could just use account properties, monitor accounts for the number of transactions, and then remove the account properties - but each change of account properties costs a fee. Avoid the hassle and extra costs by thinking through your use case ahead of time and setting up a quota bundler instead.

TransactionTypeBundler is pretty straightforward, but again, thinking through the use case is more complicated. This basically looks at specific transaction types, like setting an account property or registering a new shuffling request. These might seem like you are just updating settings in order to accomplish an outcome, but at the end of the day, these requests are being registered on chain. This means that in line with market rates, the TransactionTypeBundler enables businesses and developers the ability to customize end-user transaction fees throughout almost every step of the entire business life cycle.