These are fields that will/won't be sent from front end. My code for each of these fields is in separate if(@arr_0), if($scal_1) blocks. So if any of these variables don't exist, the related code will not execute.

You've already gotten the standard references to why symbolic references ("using a variable as a variable name") are bad ju-ju - error-prone, hard to maintain, inexplicable action-at-a-distance, and so on - but there's another piece which is very relevant to this sort of situation that hasn't been brought up yet: It allows the remote client to overwrite any (non-lexical) variable, not just the ones you've set up if blocks around.

For example, I imagine your application does some kind of access control, since you probably need to prevent random anonymous users from changing things they shouldn't. Let's say, for the sake of discussion, that your code uses a global variable named $authenticated_user to keep track of what user is logged in. Now, what happens when someone connects to your application using software they control (i.e., not the front end program that you intended them to use) and sends your server a list of parameters that includes authenticated_user=administrator?

I'll tell you what happens. Your hash-to-variables routine sees "there's a hash key called authenticated_user, so I'll set the value of $authenticated_user to the value of that hash key" and, boom, you've just handed admin access to some rando who probably doesn't even have a legitimate user account in the first place.

Just say no to creating variables based on user input. Users can't be trusted with that kind of power.