I have to say, my experience of Devise with Omniauth in Rails 4 has been so painful, I abandoned using Rails for the project entirely. It's interesting that for the de-facto "convention over configuration" framework, the article likes that Devise "gives you a nice way to configure everything". So does Spring, but that's not what I want when I'm aiming for maximum productivity.
If you compare setting up a new project in Rails 4 that lets users authenticate with Github, with doing it in Meteor, you'll see what I mean.
Configuration is usually very minimal. It might be as little as nothing to editing 2 lines in a single config file.
It depends on what you want to do of course. A lot of the following behind devise is due to how well it deals with all of the ceremony involved with standard authentication.
Everything from sending out e-mails, password resetting, failed login constraints and all of that stuff. It's nice to be able to hook in a gem and perform minor configuration to get all of that with no fuss.
In your example of only having to auth with github then yeah, I wouldn't use devise either because it's so basic. Omniauth is what I would use in that case. I would see that as a toy example too because more often than not you'll want much more than just auth'ing through a third party site.
I must have been doing something very wrong then. I was using Device and Omniauth in a Rails 3 project, and sure enough, it was very straightforward to get it working. Then I upgraded to Rails 4, and all hell broke loose.
I'm sure that, given enough time and patience, I could have figured out which methods, controllers and models I needed to write, and what to put in the config files, but it felt like a major regression convention-over-configuration. Compared to meteor (type 'meteor add accounts-github' and add {{loginButtons}}) it was really painful.
If you compare setting up a new project in Rails 4 that lets users authenticate with Github, with doing it in Meteor, you'll see what I mean.