The cases you provide are (admittedly) simplistic. When this becomes useful is when you have a method or function, and you want to document what its behavior should be

sub frobnitz { ... }

ok( frobnitz( )                       eq $no_params_results );
ok( frobnitz( @some_parameters )      eq $expected_results );
ok( frobnitz( @some_other_parameters) eq $other_expected_results );
[download]

The comparison can be any type of result that can be tested (does it throw / die, does it set some attribute on an object, etc).

The benefit of this is that you can quickly and consistently check the same behaviors, the same way, every time, after every change, to verify that you have not broken some expected behavior. This is a huge safety net when adding a feature, refactoring, etc. Your tests are, in effect, documentation, in the form of code, that translates English requirements into something that is less prone to misinterpretation more formalized.