To pick out one particular electronic component and call that the "bread and butter" is silly, as is all these "most important" kind of statements. For example, count resistors in analog circuits, and I'm sure you'll find they outnumber opamps by a wide margin.
Also, things change. There was a time when vacuum tubes were the layman's silly "most important" or "bread and butter" component of analog electronics, then the transistor.
You never need to use a opamp, but it can be the most efficient way to implement a circuit to a particular spec. After all, opamps are made from transistors, so it is possible to use a bunch of transistors (with a few other components) instead.
The attraction of opamps is that they embody a common and easily utilized building block. With the magic of integrated circuits, these building blocks can be the size and cost of single transistors sometimes. Any one opamp may be overkill for any one particular application, but the great leverage of mass produced integrated circuits allows them to be cheap and small enough so that it's usually cheaper and smaller to use a whole opamp when only a few of its transistors would actually be needed.
To use your analogy with a FOR loop in a programming language, you don't actually need to use this construct. You could initialize, increment, and check a variable yourself with explicit code. Sometimes you do that when you want to do special things and the canned FOR construct is too rigid. However, most of the time its more convenient and less error prone to use the FOR construct for loops. Just as with opamps, you may not use all the features of this canned high level construct in each case, but its simplicity makes it worth it anyway. For example, most languages allow the increment to be something other than 1, but you probably only use that rarely.
Unlike with the FOR construct, there is no compiler that optimizes a opamp in a discrete circuit to just the features that you require in that instance. However, the huge advantage of volume integrated circuit production reduces those features to way less than the equivalent of a few extra instructions in a FOR loop. Think of opamps more as being a full featured FOR loop implemented in the instruction set, which takes the same instructions to execute whether all its features are used or not, and less instructions than you would have to use otherwise, even for the simple cases.
Opamps are a bunch of transistors packed up to present a "nice" building block, and made available for the cost of just one or a few of those transistors. This not only saves time in design to deal with all the biasing of the transistors and the like, but manufacturing techniques can be used to guarantee good matching between the transistors and that allow for measuring and trimming parameters closer to ideal. For example, you can make a differential front end with two transistors, but getting the input offset voltage down to just a few mV is not trivial.
All of engineering is based on using available building blocks at some point, and opamps are a useful building block for analog circuits. This is really no different that using transistors. A lot of processing went into refining the silicon, doping it, cutting it, packaging it, and testing it that we somewhat take for granted as a discrete transistor. Opamps are more integrated than individual transistors, but are still fairly "low" level in the scheme of things.
Back to the software analogy, this is the same as using existing subroutines to get on with writing the code for your particular app. In the case of OS calls, you don't have a choice to use them. That would be like refining your own silicon. Opamps are more like convenient calls that you could write yourself, but doing so would be silly in most cases. For example, you've probably had to convert a integer to a ASCII decimal string many times, but how many of those times did you write your own code for that? You probably used runtime library calls for that, or even called those implicitly thru higher level constructs available in your language (like printf in C).
The ideal opamp has infinite input impedance, 0 offset, 0 output impedance, infinite bandwidth, and costs $0. No opamp is ideal, and these and other parameters have different relative importance in different designs. This is why there are so many opamps. Each is optimized for a different set of tradeoffs. For example, you sometimes hear that the LM324 is a "crappy" opamp. This is not true at all. It's a superlative opamp when price is a high priority. When a few mV offset, 1 MHz gain*bandwidth, etc, are all good enough, everything else is just overpriced junk.
