This is a credible effort and I enjoyed looking at it. I'd like to make a few comments about your design.

Objects aside, it is good to separate data from code. Here, the ability to read a list of team data from a file, and to use as default the MLB data from a __DATA__ section, would be one approach to generalizing the module. The separation would support introducing Team as an object and feeding the data to a constructor.

You have a well-defined level of abstraction for OO. All the information needed for identifying teams in a box score are here. All the teams that can conceivably play an official game with each other are listed. You omit complications like roster, management, ownership, and farm system.

OO design models some abstraction which is always informed by the size of the problem space. By definition, a module designer does not have the luxury of a well-defined problem space. With modules, the measure of success is the number of unanticipated ways the module can be used. Could a fantasy league use the module? Could a high school conference? Could ESPN's box score server? In that last case, you have the problem that the server may run for months or years. On the fly, can it handle league expansion and movement of teams?

There are many distinct Teams, but each is unique to itself. The constructor should produce a single instance, and all methods should deal in references to that instance. This is a restatement of merlyn's principal objection.

Thanks for posting this interesting module. I found it thought-provoking.

After Compline,
Zaxo