What the light weight OO buys you up front is a "legal" way of using FSLs. Or actually, rather than using a FSL, you are using an OSP (Object Scope Property). In other words, it doesn't really buy you anything at all on day one. However, it does make it a whole lot easier to refactor your code as it grows. There are a few minor things that may be considered advantages of the OO approach:

You might gain a little advantage by using setters on the object rather than setting random FSLs in various places - at least you can centralize sanity checking of values.

You might gain a little advantage by grouping manipulation code for particular related properties together and describe how the properties are related in a POD block above the manipulation members. Using OSPs rather than FSLs removes the need to provide all the FSLs at the top of your script so grouping related stuff in sensible way becomes easier.

None of these is a big win. For small chunks of code, unless someone has already solved the problem for you, there are seldom any big wins anyway. The best you can do is prepare the ground for later grand development, and that is where light weight OO does have an advantage.

In fact, if it is possible you may migrate to an OO solution, it's easier to not pass stuff around for your first iteration. When you OO things just delete all the FSLs and change any $FSL to $self->{FSL}. So you could argue that you ought avoid both 1. and 2. for the first cut.