balanced (currentness vs. stability) linux server distribution

Server Fault can't pick an operating system for you -- you need to make this choice for yourself.
Among the many things you should be considering, roughly in order, are:

1. Application Vendor Support
   Does the software you need run on the distribution in question

2. Internal (or regionally available) Knowledge Base
   Do you have sysadmins familiar with the distribution in question?
   If not, can you hire them locally at reasonable cost?

3. OS Vendor Support
   Is the distribution well supported by its vendor?
   Can you get appropriate support contracts (at reasonable cost)?
   Are there appropriate communication channels (security@, etc.)?

4. Management Features
   How can you keep a number of systems "in sync" with the same packages?
   How can you manage/update a number of systems without touching each one manually?

Bear in mind that "current" and "stable" are generally mutually exclusive requirements:
A distribution that keeps their packages at-or-near the bleeding edge will, of necessity, have more frequent updates, a greater chance of shipping an update that breaks your environment, and potential for security problems to come up.

When evaluating an operating system vendor you should look for one that is shipping "reasonably current" versions of software (i.e. anyone shipping Apache 1.x should be right out, as should anyone shipping software with known security holes unless they're applying local patches), but unless you have a specific need for the latest-and-greatest release of some package you should be content with what your OS vendor ships as long as it meets your needs.
Ask yourself honestly: "Will it impact my day to day operations if I have Perl 5.12 instead of 5.14?", and unless the answer is "Yes, I require 5.14 because of X." don't worry about it.

Remember also that you are not required to use the system version of any program - you can always install and maintain your own version provided you are willing to take on that responsibility. This is where management tools like Puppet begin to be useful.

If you are not familiar with the various distributions and their current feature sets you owe it to yourself to spend a few hours with a copy of VirtualBox or similar desktop virtualization software and evaluate each one after you've narrowed the field.
Determine which distribution you are most comfortable maintaining, because you may be managing it for several years.

I've had Gentoo, SuSE and Fedora in production environments... My general preference for production work is RHEL or CentOS, but each of the aforementioned distributions were needed in limited-capacity for very specific features.

Gentoo is tough to scale... it can be done, but it's not an "it just works" distribution. You've acknowledged this.

SuSE doesn't have the mindshare in my region, so that could be a potential impediment to hiring and finding expertise.

Fedora is familiar-enough to Red Hat and CentOS engineers to still be useful (with a greater pool of talent that can administer it). The problem there is the upgrade path between versions... This affects Fedora as well as RHEL/CentOS.

However, if you're doing this correctly (the DevOps way), you won't be running full in-place upgrades. Systems and application deployment should be automated and reproducible to the point where you redeploy onto rebuilt servers rather than attempt OS upgrades.