Facebook gave up too early. On the other hand, Facebook can afford the development cost of native. For many other applications, native is unaffordable, especially for multiple platforms.
(Thank you, though, Facebook, for (before giving up on hybrid) figuring-out how to shut off the *&^%$#! iOS WebView "accessory view", and using your Facebook-powers to cow Apple into looking the other way when apps go digging into the virtual keyboard windows to shut that evil thing off...)
Embedded WebViews have gotten much better. Android has been the laggard, with awful animation/transition performance and glitchiness prior to 4.x, and user reluctance to upgrade OS (improved now) and inability to upgrade on many devices (alas, not much improved, so many Android devices cannot be upgraded to latest OS.)
Certainly, on iOS at least, I think most users would be hard-pressed to tell the difference between well-written hybrid apps and native.
I use (Zebra, was Motorola, and before that RhoMobile) Rhodes. I've also developed using PhoneGap/Cordova. I would not do a large project in PhoneGap/Cordova, because everything has to be done in Javascript. With Rhodes, I write models and controllers in Ruby, views in ERB (wish it had a better template language...) and code that touches the UI directly in Javascript. It's a very comfortable platform if you have been a Rails developer, because it's very similar - the server has been placed in the application.
I'd say at least half my development time is spent with JS and CSS (actually, I use SCSS). I see that as a good thing. I can tweak the UI interactively by twiddling CSS in Safari or Chrome desktop (developer tools for both can connect remotely to a device for inspection/debug/experiment.) I can easily teach a designer to do that themselves. Contrast that to the painful process of tweaking a native UI, being forced to use platform-unique tools and go through a slow and painful build process to see the smallest result.
I've been working with a small team implementing a number of similar energy-conservation apps (they are used by professional energy auditors - organizations are opinionated, that's why there are 6 apps...). I really think the effort would have been insurmountable had it been done with native code. This is not a typical consumer app with a few screens, but ones with dozens of pages of data-collection forms (per audited building). It's not your typical consumer app with some kind of silly one-page dashboard with text in circles...
If I had to do something with charts/graphs, I certainly would leverage the great JS libraries that are available, rather than struggling with native code! We did do a little sketch tool in JS (sketch over photos for annotation - just browser API) and nobody would ever know it is not native.
Ultimately, we abandoned Android (at least for now) due to poor performance and Balkanization, but I can see Android being supported in the future again.
I have not used Xamarin. It seems the worst of all worlds to me. You have to use the native API of each platform, but you write in a common language (C# yuck!). Where is the saving in development time here?
I strongly disagree with the bit about "different screen sizes" etc. being problematical. Using HTML helps solve that problem. It's easy to create flexible layouts using responsive CSS. Yes, native platforms have gotten better about this. But it's impossible to get designers directly involved, using the tools that they are familiar with. They still have to toss wire-frames "over the cubical wall" and the battle it out with programmers as to whether their fantasy UIs are even possible. With HTML5, they can work with what they are familiar with and provide complete solutions for UI bits. As well, there is an amazing volume of free and really quite high-quality resources for CSS3 effects, etc. that can be leveraged.
Yea, if you have a million-dollar budget for a small app, go for native. The rest of us are well-served today by hybrid. Most of these are apps that the public will never see. BTW, speaking of Home Depot - those devices they carry - they're Motorola (now Zebra) devices. And they've developed internal apps for them using Rhodes. Along with McDonald's, Hormel, many others with similar needs. Just can't imagine developing these types of enterprise apps using native code exclusively! Even with dedicated devices, BYO is very important to these companies, for management, off-site, etc. Nobody wants to be tethered to an extra company-supplied device when they go home! The device on their belt might have a built-in printer or scanner, and need some specific support for that on a specific platform, but basic functionality still needs to be available on consumer devices.