Pretty much, yes - the primary purpose of exporting symbols (sub or variable names) is just so that you don't need to provide the fully-qualified name every time you reference the symbol.

The error message you got hints at the internals behind this - it complains that it couldn't find &main::say_it, but, because the sub is in package Xyzzy, its actual fully-qualified name is &Xyzzy::say_it. Exporting the sub creates a new reference to say_it in the package that you use the module from (which, in this case, defaults to package main, since you aren't explicitly inside a different package).

When you're writing object-oriented code (which is where the -> syntax is normally used), you generally don't need (or want) to export the subs implementing your methods, because they should be called from an object reference ($my_object->do_stuff()), so exporting is usually only used for non-OO procedural interfaces where the subs would be called as stand-alone chunks of code.

Also, as a side note regarding EXPORT vs. EXPORT_OK, it's generally considered better to use EXPORT_OK, so that symbols are only exported by explicit request. This helps to avoid conflicts (what if you had already defined your own sub say_it, then you use Xyzzy and it implicitly exports its own say_it?) and makes it easier to locate where things came from while debugging (if you use 15 modules that all implicitly export subs, you can't find where say_it was defined without checking every one of those modules, but use Xyzzy qw(say_it) makes it obvious where it came from).