I maintain the RailsApps ecosystem, which includes a gem that assembles various application templates (rails_apps_composer, derived from Michael Bleigh's RailsWizard), Rails Composer (an application template that generates various starter apps), the RailsApps collection of example applications, and a collection of tutorials that explain how each example application works.

The OP argues against using a "Rails template" but ultimately his argument is against using a starter app to begin a Rails project. His concerns are reasonable but ultimately shortsighted.

You see, everyone uses a starter app. Here's your choices:

1) Use "rails new" to get the default Rails starter app. Add your favorite gems and tweak everything to work together.

2) Build a starter app with you favorite gems, store it in a repo, and make a copy every time you start a new project (search and replace to change the app name in ten locations).

3) Build a gem that copies a starter app with all your favorite gems. Build in a search-and-replace script that changes the app name.

4) Build an application template that generates a starter app using "rails new -m".

#2 is faster than #1 for starting up a project (except for a little time to copy the starter app to a repo) if you are using the same starter app more than once.

#3 and #4 are faster that #1 and #2 for starting up a project but more time is required to "build the tool." Fine if you can save more time running the tool than hand-assembling as in choice #1.

But there's a problem with #1, #2, #3, #4. All starter apps are time consuming because you need to take time to figure out what's changed since you last used your favorite gems and hunt down any new tweaks needed to get your favorite gems to work together. Most developers underestimate this effort and and most starter apps, application-generating gems, or application templates end up mired in the tar pits of neglect, abandoned in the constant change of Rails and its gem ecosystem.

There's another choice:

5) Participate in an open source project to maintain a set of starter apps with commonly used gems. Since you are always going to use a starter app (of some kind), why not use one that other developers are using? And benefit from a community effort to identify and patch integration issues.

That seems to be what's driving the popularity of the RailsApps project (800+ "stars" and 150+ forks on GitHub for the rails_apps_composer gem). Here's the link:

https://github.com/RailsApps

Now about what the OP said:

"Even after the first implementation, the template must be constantly tweaked and finagled to keep it up to date."

Yep, that's where you need the leverage of a community supporting an open source project.

"Each one of the decisions that the template makes for you should be discussions within the team."

There's no reason to have a single starter app or template that generates only one stack. Take a look at the RailsApps repo. You'll find starter apps that use MongoDB, others use SQL. The Rails Composer application template will give you a choice of ERB/Haml/Slim, Twitter Bootstrap or Zurb Foundation, PostgreSQL/MySQL/MongoDB, RSpec/MiniTest, OmniAuth/Devise, etc., etc. Have your team discussion; find out what the larger community is saying; make informed choices. You can have multiple starter apps and choose the one that is appropriate for the project at hand.

"The fact is, 'best practices' are a moving target. They evolve through team communication and cohesion."

Yep, and if your team participates in an open source project to build and maintain useful starter apps, you'll benefit from the efforts of a larger community and contribute to the growth and wider adoption of Rails.