If I try to pass the variables directly to perl as arguments, (such as ovo-test.pl $OPC_MSG_TEXT), it does't store all the contents of $OPC_MSG_TEXT into $ARGV[0] -- it splits the contents based on spaces..my understanding is that this is default linux/unix behavior?

For practical purposes, yes. But to be completely correct, it is the shell which does the variable expansion and as you have said in the title in this case your shell is bash.

The variables are features of the shell and as such when you use them on the command line as arguments to other programs (perl or anything else) the shell substitutes the variables for their contents. As wrog points out, the simple way to tell the shell not to monkey with internal spacing when making this substitution is to enclose the variables in double quotes. You can test this pretty easily yourself if in any doubt:

$ dummy="What    a    lot of  spaces."
$ echo $dummy
What a lot of spaces.
$ echo "$dummy"
What    a    lot of  spaces.
[download]

It's not just spaces you need to worry about. Other characters are important to the shell and may result in unintended behaviour. See the section Quoting in the bash manpage for the full details and the bash hackers wiki for further discussion and examples.

Besides wrog's suggestion to enclose them in double quotes, you can export them, then they will be accessible in Perl via %ENV

#!/usr/bin/bash

# do other processing

# export the desired variables
export OPC_MSG_TEXT OPC_MSG_CODE

# use Perl for further processing
ovo-test.pl
[download]

#!/usr/bin/perl
use strict;
use warnings;
my $text = $ENV{OPC_MSG_TEXT};
my $code = $ENV{OPC_MSG_CODE};
...;
[download]

since the question is about about Linux and bash, you can probably skip the page about quoting on non-Unix systems; the bash manual is what you want. Most of the time, putting the arguments in double quotes does what you want, e.g.,

scriptname ... "${OPC_MSG_TXT}"
[download]

will ensure that whatever $OPC_MST_TXT expands to ends up as a single positional parameter

... and when dealing with server-type programs, standard representations such as YAML or JSON (or, of course, XML), have already solved the problem of reliably passing “funny-looking” values back and forth.   Not useful on the command-line, but intended for things like HTTP.   (CPAN has off-the-shelf support for everything, of course.)