What advantages does Features offer in deploying changes What advantages does using features to manage deploying changes (versus keeping code updated and data fresh)?

The Features way (near as I can discern):

Features takes configuration (which is ‘content’) re-envisions it as code and builds a module for it, and then pushes it up where it continues to live as an object that has to be maintained as code forever.

The next time the developers update their code, (where the best would include updating their dev database to a fresher copy of production), they get these configuration changes that they too have to manage in perpetuity.

The not really doing anything special way

The original developer updates the configuration on production, (after ironing out these changes in development), then we are done worrying about that configuration change, forever.

The next time the developers update their code, (where the best would include updating their dev database), the configuration changes are included.  No one ever has to worry about overrides and reverting ever.

Obvious Caveat:

If the original developer changes 103 individual settings, remembering and setting them all would be nightmarish.  In this case I would understand using a configuration packager, which is more or less how Features is used, to set the production system to match. But then what?  I don’t understand keeping that project alive after you have updated the settings on prod to match what you did in development.  Features as a fire and forget config missile, I get... as code... I don't get maintaining it after the fact.

===================================

I started out this post open to Features, after it was regaled by some incredibly trustworthy Drupal gurus.  I had a bad feeling about it, but hoped it would wane.  After writing this, again find myself frustratingly opposed to something everyone else seems to think is the best thing since sliced servers.

The features ideals I can’t wrap my brain around:

I have always approached Drupal with a philosophy less eloquently described by one aforementioned gurus as: “Content comes down, code goes up.”

In Drupal 7, configurations for the system and modules is stored in the database.  The dotted line I've drawn in my perception demarcates content from code is right on that line; code is stored in files managed in Git, content is entered into the UI and stored in the DB.

Using Features for Structure:
On my gut feeling about exports and features, another Guru said: “It’s going to end up in a file one way or another”.

I didn't argue at the time because I wasn't seeing his perspective and wasn't comfortable calling him on it (guru vs. marginally experienced flounder).  

I've never thought about it because I wasn't using the paradigm he was thinking about (developer).  I had always just imported the structure, because my brain is always in a different paradigm (site builder) when I’m working with structure.  

I haven’t ever done it the way he described.  It is actually clever, and I can see using that method in certain cases.  I realized later when my brain was back in developer mode that I have done something similar this, in a different sort of way; I use Form Builder to build rough forms quickly, then drop them into my code, I don’t export them, because Form Builder gives you access to the code for their construction as you build them out.

This makes me hesitant to say “Features is teh Ahhsumz”

So what am I missing?
You seem to have mentioned the use-case of Features only as a configuration packer, probably with strongarm, or with structure - where you would not use the code once it is run and has made its changes in the database.

But one of the important uses of Features is ctools exportables, such as Views, rules, etc... Here, the settings are much more complex than '103 configuration options' and if you are dealing with multiple developers, a staging site and then production, you can't imagine doing all of this manually on all different servers and instances.