Many see /o as a performance enhancer first, with the side effect of locking in the state of the first variable interpolation. I maintain that locking in the state of the first variable interpolation should be looked upon as the primary effect, and enhanced performance as a distant second side-effect. Chances are good that you don't even really need better performance in the particular segment of code that uses an RE with the /o modifier. Only profiling can tell you for sure, and even that should probably only be used if the entire script isn't meeting its speed performance needs.

In either case, /o has been mostly replaced by the qr// operator, discussed in perlop. ...and /o remains in the Perl vocabulary, IMO, for backward compatibility more than anything. New code going forward should almost always use qr// instead of /o, if for no other reason that qr// is clearer and easier to maintain.