The function used to construct the initial comment string is comment-padright. Its doc string says:
comment-padright is a byte-compiled Lisp function in ‘newcomment.el’.
(comment-padright STR &optional N)
Construct a string composed of STR plus ‘comment-padding’.
It also adds N copies of the last non-whitespace chars of STR.
If STR already contains padding, the corresponding amount is
ignored from ‘comment-padding’.
N defaults to 0.
If N is ‘re’, a regexp is returned instead, that would match
the string for any N.
Ensure that ‘comment-normalize-vars’ has been called before you use this.
It is used by comment-region (through its subordinate default function comment-region-default-1 as follows:
...
(let ((s (comment-padright comment-start numarg)))
...)
...
to construct the opening string.
As the doc string states, If STR already contains padding, the corresponding amount is ignored from ‘comment-padding’. That explains why the extra spaces in comment-padding don't do anything. But why do the colons matter in the previous case? A comment in comment-padright itself explains that:
...
(if (not (string-match-p "\\`\\s-" comment-padding))
;; If the padding isn't spaces, then don't
;; shorten the padding.
comment-padding
(substring comment-padding ;additional right padding
(min (- (match-end 0) (match-end 1))
(length comment-padding)))))))
...
It's only spaces as padding that are discarded. See the code in newcomment.el. The line number in this link is correct at the time of writing, but it may change in the future, so you may have to search a bit to find the comment-padright function.
So the behavior is as designed. Why it was designed this way however is another matter: I suspect that a choice was made on which reasonable people might disagree. If someone musters a compelling argument for doing it a different way, then a bug report describing the use case might cause the developers to make appropriate changes.