Ovid says in a comment:
In fact, the only reason SmallTalk really interests me right now is the "pure" OO model that I keep hearing people talk about. However, I'm brushing up on my Java because that's where the bulk of the work is. Until I hear convincing arguments about how SmallTalk can improve my professional life, I'll probably just wonder about it. I have a pretty active social life, so I don't have as much time for research as I would like.
Ovid, let me tell you without reservation, learning smalltalk will improve your professional life. Here's why.
First of all, in The Pragmatic Programmer , the authors recommend learning a new programming language every year, just to stay sharp. Ideally, you would learn the syntax, the programming model, write a few beginner programs and finish a non-trivial application. Find out how it feels under your fingers. Get exposed to some new ideas. See which ideas look good but really chafe, and which ideas look bad but work quite well in practice. Your goal isn't to beef up your resume, but to learn and adapt.
Realistically, doing all that work is time consuming. I've been doing my best to follow the intent of this dictum, and I try to read about one text per year on a language I do not use, or haven't used in years. Once you've done the grand tour of programming (procedural, recursion and functional, OOP, and declarative programming), it should be easy to pick up some of the basic insights a new language brings. It may take weeks or months for the ideas to fully sink in, but in time they will. You'll start looking at your code differently, and start seeing better ways to write in the language of your choice that make your programs more robust and less tedious to write.
Yes, this is the Evelyn Wood School of Learning a Programming Language. That's OK. You'll learn something, and there's nothing preventing you from going back over a text, like SICP, a second or third time. Or taking an opportunity to write a little app with Rails instead of Mason.
That aside, the second key point: if you are going to try and learn a new language to broaden your horizons, pick something different. Most programming languages out there today inherit something from the big Ur-language known as ALGOL. If you've learned one ALGOL derivative, you've learned most of them. So, for example, if you already know C, spending time on Pascal isn't a great investment. Better spend your time on something very different or unique, like a Lisp, Smalltalk, Forth (including PostScript), Self, *ML, Haskell or Prolog. There are many more ideas to mine there than there are in the language next door.
Third, with all of the programming languages out in the world today, there are very few great languages -- stuff that lasts for decades. Many of those great languages are sui generis, like Lisp/Scheme, Smalltalk and Forth. These languages are a programmer's Latin, Greek, and Aramaic. Many of the ideas that come into Objective-C, Java, Ruby and Tcl can trace their origins back here. If you want to learn a new language, focus here before you kick the tires on something newer like Python, PHP, Tcl or Ruby.
Fourth, why Smalltalk? Even if you don't fire up an image, the whole model behind the language is wonderfully elegant. Sure, there are warts in there (like the lack of an if statement), but every language has warts. Get over it. Look for the deeper values like Collections, blocks and metaclasses. Stare at it long enough, and you'll wonder why any method in an object oriented system needs more than ~ten lines of code. And the whole thing will be much easier to understand than you ever thought it could be.
One last note. On the local XP list, someone mentioned cyclomatic complexity as a means to identify complex code in a project that needed to be refactored. However, in an object oriented project, cyclomatic complexity doesn't work, so someone offered lines per method as a suitable replacement. If most of your code is hovering around the 10 lines/method, you know methods that are 50+ lines long desperately need refactoring.
This metric and the associated style of development come from Smalltalk. Had I been stuck in a rut writing 500-line Windows event handlers in C (with case statements -- YUCK!), that suggestion would have floated over my head. As it stands, I'm using that style to guide me in refactoring procedural code into object oriented code at work right now. I'm moving Tcl code into XOTcl, but it doesn't matter -- I'm programming as if I were building a system in Smalltalk, and the new system is much better for it. The codebase could just as easily be in Perl or Java, but the approach remains the same.
Learn Smalltalk. I assure you, it will improve your coding life, even if you never manage to use it professionally.