None. 24/6 is quite good - thee are systems where mainteannce is a real problem.
The main problem can be - and please do not edit out the blunt langauge - if some morong stupid architects have NOT designed the system for 24/6. I.e. if it does not work with replication, or needs exsessive maintenance (on the free day) so that the admin has no chance to do system level stuff there.
If it is designed for using all features of the sql server for uptime, 24/6 is a quite good and easy to work with SLA.
You also may have a small maintenance window every day - you did not say that, but I know even forex sleeps an hour per day simply because no major location is having busienss hours during this time. And forex is unregulated. It may thus be you can do some small stuff daily.
That said, a good design would likely partition the database by location (or a group code, so you can keep all european in one server, all american in one) and allow sharding - if US markets are off, the US responsible servers would not update. As "contintens" mostly share timezone (yes, I know the america cover more - but not excessively so) that gives you maintenance windows for every continent.
Cloud based likely will not work at all because cloud based is small stuff only. Try finding someone offering you a cloud storage for a medium size database and you be surprised. Hint: medium size likely is 100gb+. It also depends what "stock trading" does. Do you test strategies? Large scale? I currently do only futures trading - 22 symbols - and our simulations generate around 50gb-75gb data per day for analysis AFTER compression. 200 before. I utilize partitioning in staging (sql server) just to be able to delete bad results fast during regular maintenance - otherweise I would do multi hundred million row delete statement. The last risk management database I build for a customer (energy, not stocks - so less symbols) had a space allocation of 20 terabyte and was using an Oracle ExaData hardware cluster (in 3 copies - in 3 locations, replicating). It really depends how large the customer scale is for this.
That said, here is something really to think of: what is "stock trading"? If it is "manual" or "automated slow" then this is not too demanding - even 1000 traders wont do a TON of trades from a db perspective.
If it is HFT - High Frequenvy Trading - you may have a single algo in a single stock sometimes doing 100 trades per second. Add many markets, many symbols, many algos and you can not scale that in sql - this is why those algos write logs, keep things in memory and you then regularly import the transactions from the logs. Real time is NOT doable for HFT in SQL - especially not because it would impact the machines (slow down the trading side). When you cound millionths of a second (and yes, they work by now in microsecond scale) and use programmed hardware (FPGA) to make the price feed parsing to be faster than the next machine - you really decouple things. By the time SQL decides to commit the transaction about the purchase, the price may have moved too far ;) And no - do not say multi threading. I know some of the infrastructure. Thos algos run one thread per core, hard wired to the core, in burning mode - and endless loop checking for the position the other core has put the data. You easily may get 20.000 transactions per SECOND peak load from someone trying to do arbitrage between US stock markets alone. That is per exchange - and there are some.
As I said - this is a very complex system setup. A lot depends on the architecture.