1. new is a constructor. It creates an object which may include doing a little house keeping to get the object into good initial shape. In this case it is generating a lookup table of the allowed column headings for internal use by other members of the class (setOptions and getOptions for example).
2. load as you surmise is loading the hash. It is also providing empty strings for any missing columns and is providing a sort number based on the file line.
3. "simply open and print" don't work for a hash. save ensures that only heading colums are output to the file and that they are output in the correct order correctly formatted. Actually both save and load could be beefed up to work with quoted strings and embedded newlines etc, but if you want that you'd have them use Text::CSV to do the heavy lifting. And guess what? All classes derived from OptionsBase then get the new magic at no added cost!
4. Look at the line where @badOptions is set and figure it out now that you have had a sleep. setOptions and getOptions provide checked access to options. In particular they check that the options that you are getting or setting are ones that are allowed for the options class. That allows you to catch bad option stuff early make it easier to catch programming errors.
5. ISA doesn't care where the base class comes from so long as it has been seen by the time methods are called on an object that needs to access the base class definition so it doesn't matter where OptionsBase lives. It would be usual for TwitterOptions to live in its own TwitterOptions.pm module and for that module to use OptionsBase in the OptionsBase.pm module.
6. I'm not greatly interested in addressing your specific implementation details in the example I gave. Those are for you to sort out. However it makes sense to have a single cohesive class to handle reading and writing a set of options to persistent storage so I provided a load and save.

The point of the example is exactly that you have a piece of common code (get_hash) that is used all over the place but presents a very raw and unsafe "interface". By wrapping that up in an object you can easily tailor it to different contexts (different lists if headings for example) and gain a cleaner way of managing your options with better sanity checking of usage. It also makes it easy in the future to change how you persist the options. If for example you were to realise that databases were wonderful (unlikely I know ;) ) and wanted to switch all your option files over to database tables you can facilitate that in one place by simply changing OptionsBase.