Byte count is the default winning criterion in code golf. Counting bytes (as opposed to characters) is reasonable, because a language that uses more characters needs more bytes to define them.
Consider the last sentence but "negating both sides": a language that uses less characters needs less bytes to define them. Assume a certain language L only uses the 95 printable ASCII characters. A program written in L consisting of 30 such characters could for example be 256-encoded into 25 bytes (
ceil(30*log2(95)/log2(256))). My proposal is that as byte count we use those 25 ("equivalent bytes"), not 30 (let me call those "byte-digits").
It could be argued that the language L should just use a character encoding with 256 characters, which avoids the problem: that way the language exploits all code space provided by each byte-digit, and byte-digits correspond to equivalent bytes. However, there may be reasons in favour of using only the 95 ASCII printable characters. Or it may be the case that the language has already been designed that way.
Consider that someone designs a new language M which simply takes a program in language L and 256-encodes it (with some correspondence between the obtained bytes and a set of 256 characters). So the program with 30 byte-digits in L becomes a program with 25 byte-digits in M. A compiler for M would be very simple: base-256 decode and call language L's compiler. Let's avoid that unnecessary and ugly step.
Of course, the winning criterion can always be defined in the challenge. So instead of "the code with fewest bytes wins" it could say "...multiply your byte count by
log2(B)/log2(256) and round up, where
B is the number of characters your language uses". I propose to make that the default criterion.