I am not completely sure, but my guess is that the lack of extended properties on Azure might have something to do with the very complex metadata model Microsoft has adopted for SQL Server, and specifically how it manages resources and performance.
As we know, the metadata in SQL Server is spread out in several locations - there are base tables in the master database (these contain system-wide configs and metadata), there are some base tables tables in each database for its own metadata and settings, and there are some base tables in the resource database. In order to "get the show on the road" with the metadata, there are quite complex dependencies between the metadata stored in different places.
Hence, my guess is that it was much easier to leave behind some of the metadata features in Azure, just so the product can be rolled out to market (after all, the delay is big enough already).
And, by the way, the lack of extended properties in Azure is a relatively insignificant problem compared to other much bigger ones: performance, flexibility, supported data types, optimization and so on...
Make everything as simple as possible, but not simpler.