There's no "functional" downside to using ERC721A over ERC721 if you are going for sequential mints anyhow. The same differences between ERC721 <-> ERC721Enumerable pretty much apply to ERC721A <-> ERC721Enumerable.
There's absolutely no stability concern (whatever that even means). It's designed to behave exactly the same way as ERC721. From an interface perspective (say you only had the contracts bytecode and not source code) it would be very hard to differentiate ERC721 and ERC721A (unless you look for the obvious factors such as mint gas costs). This is of course, because it was designed in the way to show the exact same balances, the same ownerships, emit the same events as the standard ERC721.
The only downside is perhaps, that you are basically "offloading" the mint costs to whoever is the one to next trigger the transfer (typically the buyer on OpenSea). If you add up these gas costs (minting + transfer to a next owner) and compare the implementations, you'll probably spend roughly the same (or even slightly more) in total gas. Although this is in many cases still preferred, because these transfers often occur at times where gas is low, whereas minting can often spike up gas prices for very hyped projects.
I won't even go into the details of ERC721Enumerable, because it adds a serious amount of additional gas (which I see in no way justified).
Source: Had multiple PRs in ERC721A