On the ITN there can be something of a “death spiral”. You don’t have enough delegation, you make no blocks, your performance falls so your chance of gaining delegation falls. I tried to run a pool as an experiment and failed miserably (no ada was made in the course of the experiment, but some real money was lost on compute time :)).
If you’re lucky, you will at some point be picked and produce a block (as with your pool), in which case your performance spikes for an epoch. However, no sane delegator will touch you, so your performance falls again - you will have low desirability. On the mainnet, your pool would simply be starved at that point. a0 does influence desirability, but only because of the impact on rewards. Even with a0=0, the pool will not be desirable if it does not consistently produce blocks.
Fortunately, on the mainnet you will be rewarded on apparent performance. This measure can include an assessment of how well you do against your statistical behaviour. You will be higher in the ranking than on the ITN, there will be consistency of rewards, and you can attract delegation. You will be a desirable pool.
You could also, if you choose, use pledge to make your pool more desirable, in which case you would be raised higher in the ranking or could charge a higher margin, but there is no mandatory minimum pledge level, and the pledge that you require to achieve a higher ranking will depend on other public pool operators. In equilibrium, the model shows that all top-ranked pool operators will receive a similar RoS regardless of their ranking.
Remember also that if pool owners put too much pledge, they will be saturated and lose rewards. This means that their desirability will reduce, and delegators will choose alternatives. They will split their pledge and start another pool, or run as a purely private pool.
The main protocol parameter to be concerned with is “k” rather than “a0”.