Yes, the '_' makes it accessible as an attribute name.  But the presence of '-' in the option name has a UNIX history.  That is a flag like '--a-b-c' is typical, '--a_b_c' is not.

There is less of precedent for a flag like '@@a@b' or '--a@b'.

Here's the relevant code from '_ActionContainer' class.

    def _get_optional_kwargs(self, *args, **kwargs):
        # determine short and long option strings
        ...
        for option_string in args:
            # error on strings that don't start with an appropriate prefix
            if not option_string[0] in self.prefix_chars:
                ...
                raise ValueError(msg % args)

            # strings starting with two prefix characters are long options
            option_strings.append(option_string)
            if option_string[0] in self.prefix_chars:
                if len(option_string) > 1:
                    if option_string[1] in self.prefix_chars:
                        long_option_strings.append(option_string)

        # infer destination, '--foo-bar' -> 'foo_bar' and '-x' -> 'x'
        dest = kwargs.pop('dest', None)
        if dest is None:
            if long_option_strings:
                dest_option_string = long_option_strings[0]
            else:
                dest_option_string = option_strings[0]
            dest = dest_option_string.lstrip(self.prefix_chars)
            if not dest:
                msg = _('dest= is required for options like %r')
                raise ValueError(msg % option_string)
            dest = dest.replace('-', '_')

Even if you need to have odd ball characters in the option flag, you don't have to settle for them in the 'dest'.  You can always give the argument a nice looking 'dest'.  

That's a rather common pattern in 'argparse'.  Provide a default handling for common cases, and provide parameters that let the user override those defaults.  The net effect is to limit the complexity of the code, while increasing the complexity of the documentation.