If the ad is rendering inside a "sandboxed" iframe, its rendering is delayed until content etc has loaded. This sandboxing also has the effect of not allowing ads to measure certain user behaviors and also ensures the ad doesn't negatively impact the speed that the ads are loaded. The AMP sandbox even allows the AMP runtime - if it decides there are too many "sandboxes" on the page - to simply unload some sandboxes from the page (prioritizing those the user has scrolled past). This means the AMP runtime can elect to delete ads on the page if it so chooses. While this is extreme, it does speak to the level of control and authority that is given to the AMP runtime when rendering ads - or anything, for that matter - on an AMP page. AMP does not allow an ad to measure its own viewability (because it can't interact with the top-level AMP document which gives it the necessary information about when it's in view), there is a function that ads can use to call when they're viewable. This will call enable the ad to specify a that the AMP runtime will call when the ad is viewable, though it's not immediately clear to me how this allows third parties to independently verify viewability.
The ad called by the amp-ad tag can also be written in a subset of AMP, as a special AMP-compliant ad. In this case, because the sizing etc is known, the amp-ad tag will render the ad directly into the page, and not in a sandbox. It is immediately rendered (in something called a shadow DOM). This process, and its interaction with the AMP runtime, is many times faster, but does create many more restrictions for the developer of AMP ads. Fundamentally, AMP ads can only access just a subset of AMP functionality and are restricted in various ways by the AMP runtime.
AMP ads are further restricted in a number of ways. There is an absolute limit to the length of the ad's CSS, it only allows certain CSS transitions / animations, AMP ads cannot call other AMP ads (meaning pass-backs etc are more challenging), and only a subset of all HTML is allowed. Further, because the AMP ad would be integrated into the layout of the AMP page like normal AMP content. AMP can't trust that any old ad request will return proper AMP, though, so AMP-compliant ad servers have to be blessed by the AMP team and return special cryptographic information.
AMP, at its core, is about loading and rendering content immediately, and handling everything else later. Ads are part of the "everything else" - and if you visit an AMP site, you will likely see that the AMP ads are slow to load, if they render at all. AMP is not good for publishers if they can't monetize. One main reason is that because, as previously discussed, the content of the page is cached and loaded very quickly - it is ready very quickly. Ads still load at their normal speed, which is less quick, and since they're further demoted by AMP, it's even less speedy than AMP. You can't cache ads the same way because that wouldn't work in a real-time context. The AMP 4 Ads initiative was meant to achieve something of a compromise - to allow ads to be rendered quickly (though not as quickly). It is very early in its development (TL is an early supporter), but - as discussed above - is not without its own flaws.
The AMP initiative is open source and hosted on GitHub. It is actively being developed. With several publishers recently pulling out of Instant Articles, there is likely going to be increasing momentum behind AMP. As a result, it is likely that many of the current shortcomings will eventually be addressed in one form or another - so, while it's still somewhat difficult today - I'm optimistic that AMP will be successful for mobile web monetization in the future. Eventually.