Good point.
If the double "acct4" item in the original code is not a typo but rather intended to demonstrate special handling for duplicate entries, then the OP would need to explain how exactly such cases should be handled.

One possibility would be to strip all duplicate items from the list before merging (e.g. using the uniq function from List::MoreUtils). However, whether that is the correct thing to do would depend on the exact specification of the intended outcome in the general case.

Update: The odd-looking +{ ... } in the map expression serves to disambiguate the { ... } as an anonymous hash reference constructor rather than a subroutine block. The statement return map { { $ar_1->[$_] => $ar_2->[$_] } } 0 .. $#$ar_1;
serves just as well (but note there is now no , (comma) between the outermost terminating } and the following 0).

$a || $b || 1; stops "used only once" warnings for both $a and $b. Another way to do this would be with no warnings 'once'; but that's less specific and could potentially mask other, unrelated problems (see perllexwarn).

The + in front of { $a => $b } indicates to perl that this is a hashref — without it, perl interprets { $a => $b } as an anonymous block.

Notes on your code:

In scalar context, @some_array evaluates to the number of elements in @some_array, so my $vals_1 = @{$got1}; will result in $vals_1 having a value of 6 (ditto for $vals_2). This would have resulted in messages about trying to use 6 as an array reference. (It would have been better if you had shown your error messages rather than just saying "... having issues ...".)

The output you say you want ($VAR2 = [ ... ];) is an arrayref; however, your code is populating hashes. Take a look at the Perl Data Structures Cookbook.
If the output that you indicated you wanted is not correct, please clarify what you do want.

In the context of your code, where you use print Dumper %data; you probably want print Dumper \%data; (ditto for print Dumper %hash_of_data;). Take a look at Data::Dumper.

That strikes me as a drawback. After all, there seems to be nothing inherent in the organization of the two source arrays to suggest such a limitation. Why shouldn't one be allowed to end up with data like:

Sometimes one has data structure which have to be unique, then using a hash is handy.

Sometimes not ... I'm just listing another way to do it for one of those loosely defined PM requirements... :)

FWIW I'll change my post to make the restriction clearer ...

update

The question is rather how to design functional constructs like map which can easily (idiomatically) be used/combined to create nested data-structures which solve all possible requirements (sorted, nested, unique, non-string keys, ...).

Thats more a design than an implementation question, I rarely see people using List::MoreUtils here.