SQL is the same way- it suits my "power user" style by allowing me to type in a piece of script, hit the checkbox to find errors (or run it in a test environment), debug, rinse, repeat. Then I can stitch together all these pieces into one giant operation and let it run.
I would love to learn Python but as OP says I also have a job to get done. Every time I sit down with a Python tut, it seems (maybe just my perception) that there's so much fundamentals, coding, etc before I see the output what I'm actually doing. That there is a larger upfront investment than there is when learning Excel or SQL.
The worst SQL is done by people who treat it like a programming language.
I've taught SQL to non-developers and most pick it up pretty easily as long they're taught the right way.
SQL is a declarative programming language. It's probably much easier to learn for people with experience in functional programming (where you also specify what you want, not how to get it), and tools like Excel, than people who are used to thinking about telling the computer what to do.
This is known as declarative programming, and is the basis for functional programming languages like Lisp and Haskell. http://en.wikipedia.org/wiki/Declarative_programming
It's a different paradigm, but one worth exploring if you're only familiar with imperative OO.
I could go on and on, but the short order is this: Pandas has an object called a DataFrame which maps 1 to 1 with a sheet from an Excel file. You can pull in two sheets of data from Excel, do merges, joins, iterations, you name it. I am a professional who also "has a job to do", and after two 1 hour sessions in the evening with Pandas, I immediately began using it at work to manage the huge quantity of spreadsheets my team is generating, combined with output from various databases. Anyone who knows SQL will love Pandas, because it allows you to very simply and easily conduct SQL style set logic on data without having any of it in a database.
The biggest difference that I have seen regarding the Excel vs programming issue is the level of transparency that is provided in each. In excel, you get immediate validation of your functions and operations because you can see the results at each step. However, the formulas/functions themselves are 'hidden' and as the number of operations gets larger, it gets increasingly difficult to track and control the process. This makes debugging a nightmare. With programming, the results of your operations are much less transparent, but as you get familiar with the language you learn tricks to quickly summarize your data in ways that provide meaningful feedback for what you are trying to accomplish. More importantly, your script contains a concise record of all of the data manipulations and operations that you are performing, making debugging a much simpler task (compared to a monstrous spreadsheet).
An additional benefit to programming is that, after a certain level of familiarity with the language, your productivity increases dramatically. People using excel tend to be much more deliberate and cautious when creating the spreadsheet because debugging is such a pain, which means they tend to operate at a much slower pace. With programming, you can quickly pound out a script (often without even testing the various pieces of it) because you know you can easily debug the thing afterwards. From my experience, the difference in working styles results in almost an order of magnitude difference in productivity (what would take me an hour or two to create with a programming language could take a day or two to whip up in excel) and even with the extra deliberation/time, errors are still just as prevalent in excel. (And this doesn't even take into account the fact that it is much, much easier to reuse code than it is to reuse a spreadsheet).
It's a bad thing, though, when it is used for a very consequential analysis. If the right answer is very important, you have to do what it takes to make sure it's the right answer, regardless of the tool you use. It's okay to use Excel (I love it), but you really ought to have an "expensive" developer using it.
I was doing a contract for a financial firm, and I prototyped my solution with Excel. They were so pleased, they started using the prototype immediately and begged for additional features. I complied, but told them I should do some serious testing first. They were confused by this. "What is this 'testing' of which you speak? Are you saying it doesn't work?"
I tried to explain "testing" to financial people who had been using Excel for years. They weren't buying it. "If it works, it works," they informed me. I had to sneak my testing in to the new feature dev schedule.
At a later point, I told them I couldn't add anymore features until I had refactored what we already had. Of course, if they didn't understand testing, they really didn't understand refactoring, but I had noticed similar functionality emerge in multiple locations, and I wanted to put it in one place, test it, make it unmodifiable by users, call it from wherever it was (or would later be) needed, and use my testing system to make sure the spreadsheet still produced the same tested outputs from the same inputs after each refactoring.
These experienced Excel users were quite sure that this "refactoring" nonsense was all gobbledygook that had nothing to do with Excel. "You don't have to do all that stuff if you use a spreadsheet; that's why people use spreadsheets."
Again, I think Excel is a terrific tool, but as self-serving as it is to say so, I think that if you are using it for very consequential analyses, you really need to treat it like a "real" software development platform and use "real" software dev people and practices for your development.