You posted three links to the android documentation that don't address sedev's point at all.
Your first point doesn't address the "falling back gracefully" part. The second part of that example, the ActionBar, which was introduced in ICS, IIRC, only has a community shim. Granted if you want to use a new API that may not have as much community support as the ActionBar, you either code one yourself (strengthening the sedev's point that you have to design the same functionality across multiple versions).
Your second point is even more off base. With the web's responsive design, I have to make one HTML file, and one CSS file, and if my design is sane, it works across all screen sizes. Your second link requires you to hand code different layouts for every device size which is hardly a solution - infact you are back squarely where you started. And I'm unsure if you actually read those tutorials but they don't even seem to have been updated since eclair. IIRC, you only had to deal with 3 sizes then - ldpi, mdpi, and hdpi. I haven't done Android dev in a while, but I'm sure the number of layouts have tripled.
If you really want to counter sedev's point, you should point to an app with the relevant code that actually does what sedev is talking about and not some links to the documentation. Everyone is already aware of the documentation, and if it actually worked as you said it did, we would not be having this conversation.
As RyanZAG explained, your multiple layout files should only re-organize fragments.
Yes Android dev is hard, with multiple versions, sizes, formats and bugs. But there is documentation, tools and example to adress them. Deal with it.
If you are willing to try again, as so many things have changed since Eclair, you can have a look at this exemple where you will see how you can use new API and a fallback when they are not available: http://code.google.com/p/android-protips-location/source/bro...
You just make your app out of fragments and then use different layouts based on screen size to arrange your fragments. It's pretty straight forward and really not the problem. For general reactive design like on websites, you can just set up your layout in XML to grow correctly to fit the screen, which is something it does by default.
The real problem is that Android very heavily links layout with function. In HTML-land, a designer who knows a bit of html and css can happily redesign the layout of the page. In iOS-land, a designer can use UIBuilder to redesign the layout of the page as well (they usually break it too by dragging stuff inside other stuff, but it's visual and generally fixable). In Android, redesigning the layout of an app is generally very complex and nearly always requires major code changes because of how fragments are forced to interact through the activity god object.
I do not know how graceful falling back is in web development, but there are some non-graceful holes in what can be accomplished with Android compatibility libraries
The biggest design-impacting issues I've encountered are the absence of expandable or interactive notifications pre 4.1 and limitations in styling/visualizing list selection states pre 3.0
Oh, really?
Let's take a look shall we:
1. Using new APIs if available and falling back gracefully if not: http://developer.android.com/training/basics/supporting-devi...
2. Adapting your layout and UI to each device based on screen size, density and other features: http://developer.android.com/training/multiscreen/index.html
3. Libraries to help use newer features while being backward-compatible: http://developer.android.com/tools/support-library/index.htm...
And so on. Looks to me like there's plenty of infrastructure to help building responsive apps if you want to.