Google's external storage ContentProvider is terrible: slow, buggy and lacks a number of basic features. It does not work as replacement of existing file managers, since it does not properly support searching and it's performance is abysmal, compared to using filesystem directly.
AFAIK, there is still no proper support for selecting a file by extension: https://stackoverflow.com/questions/45573171 — if your file extension isn't in Android MIME database, this is it for you. The mime-filters for file extensions are completely broken: https://stackoverflow.com/a/31028507/1643723. It is possible to work around that in file manager application (by using queryIntentActivities with different, modified Uri), but built-in Storage Access Framework file browser does no such thing.
MediaStorage used to have tons of crippling bugs. Wrongly reported file sizes, delayed file addition, files, filled with zeroes... Some were fixed in preparation for Android Q release, but I doubt, that all of them did. MediaScanner is abhorrent by design.
The options for flexible content generation are still bad. Prior to Android P you had to use pipes, which resulted in non-seekable files. ProxyFileDescriptorCallback remedied some issues of that approach, but it does not support FUSE interruption events — https://issuetracker.google.com/issues/38444582: if you open a buggy FUSE descriptor, your app gets STUCK (and closing the opened descriptor from another thread won't not unblock you!) In effect, using files from other applications can now hang your app (it could before too, but only during ContentProvider#open() stage, now read() is broken too). The bug is trivial to fix, but there is still no fix 3 Android versions later.
Google Drive is a great example, how NOT to mesh OS development and app developer interests. Google Drive does not properly implement Google's own DocumentProvider API — in effect, forcing third-party app developers to use it's proprietary web API. That's great for Google (vendor lock-in and all), but not exactly great for third-party apps, because the DocumentProvider API is effectively not cared about (see ProxyFileDescriptorCallback fiasco above). If one extrapolates this behavior to future Android development... imagine, that INTERNET permission is abolished, and you have to use Google's proprietary API for every single thing. Want to download a file? Use Google Downloads (tm) API in Google Services (the system DownloadsProvider will of course be broken as usual). Want to send analytics? Google Services! Crash reporting? Firebase. Communications? Cloud messaging. p2p file exchange? Too bad for you, — that kind of advanced functionality will likely require Chrome OS!
The extrapolation above may sound overly pessimistic until you realize, that Android developers already made great many steps in that direction. Half of OS functionality is locked behind "system"-level APIs, that aren't accessible to ordinary apps, ever. But Google Services can of course continue to use them! As Mark said in his article, “the writing was on the wall”, although a lot of people (himself included) don't want to fully accept it.