Think for a moment about carrying out the trash. It's crucial: to do without it things quickly turn sour; on the other hand, the total return from garbage-hauling is limited. In your office, you need a well-made waste-paper basket--but gold-plating it makes the contents look no prettier.
Expect operates at roughly that same level of prestige. While Expect has interesting general-purpose programming capabilities, I see it used almost entirely in limited and often "one-off" roles. 'Need to run an update on two-hundred active network elements? 'Have to reset passwords on three thousand hosts? 'Want to configure a factory monitor whose menu-driven entry system only takes a minute to learn--but still takes a minute to use for each of the eight hundred components your plan must monitor?
Notice what's common to all these examples: you could solve them "by hand", given several hours or days of concentrated effort, and you only need to do the work "this one time". Moreover, each of them is "stupid", in the sense that a perfected architecture would probably use a clever buzzword-compliant (public-key infrastructure-enabled, XML-based, standards-compliant, transport-invariant, ...) approach to achieve a permanent solution. If you're like most of our clients, such an architecture is only eight months away.
For those of us looking to move on to better things, though, Expect is great. In this perspective, Expect is a handy tool, easy to pick up and use in many of programming's messy situations, to achieve a result in a half-hour, rather than a full day. It might yield results that are a little fragile--but if you spend half a day thinking about better solutions for the future, you're still ahead on the whole.
I highlight Expect's capabilities because they're so often underappreciated. Students are accustomed to hear about trade-offs between size and time, or efficiency and maintainability, comparisons which often turn invidious. It seems harder to get across to them good judgment in deciding how much to automate a particular task: enough to use "manual labor" well, but not so much as to fester crisis in the short term.
Let's call it "agile network management": just enough programming to meet the requirements.