To me, it seems that your approach is working against this maxim. You are embedding the irregularities in the code. Sure, they are data in the code, but you have to work out that fact because you build up a list of 1-5 and 19 and attach gee37 to the end of it.

I think that this:

@obj_args = qw/ arg1 arg2 arg3 arg4 arg5 arg19 gee37 /;
for ( @obj_args ) {
   ...
}
[download]

Is clearer. In this example, you've clearly separated the irregularities into a data structure and used that to drive the code.

This kind of separation has all kinds of maintenance advantages, not just clarity on first reading. Say the maintenance programmer is confronted with a case where the arguments arg3 and gee37 have strange behavior. It's easy to change the code for this and you're doing it in such a way as to make it very clear if someone else working with the maintenance programmer would immediately grasp the intent.

I much prefer:

# @objargs = qw/ arg1 arg2 arg3 arg4 arg5 gee37 /;
# 
# test just arg3 and gee37
@objargs = qw/ arg3 gee37 /;
for ( @objargs ) { 
  ...
}
[download]

To this:

#for (map("arg$_", 1..5, 19), "gee37") {
#
# test just arg3 and gee37
for ( qw/ arg3 gee37 / ) {
  ...
}
[download]

This shows how the irregularity of the data is more clearly separated from the code. When you use something like:

(map("arg$_", 1..5, 19), "gee37")
[download]

You are using code to represent the irregularity of the data.