We have a few goals for the language used in security labels (expressions made up of operators and authorizations): they should be easy to read by human and by computer, and they should be unambiguous, the Boolean logic operators should be easily distinguished from the atomic authorizations, labels should be backwards compatible forever, and the language should be extensible to anything we might want to do with it in the future. To support backwards compatibility while leaving room for extension, we originally reserved all non-alphanumeric characters and only allowed alphanumeric characters within authorizations. When our users asked for '_', '-', and ':' for use in authorizations, we added those to the white list. Moving to a black list approach is a bit more limiting to extensibility, but I think it can be done while preserving the possibility of adding future capabilities.
Supporting escaping of reserved characters might be another option, but that might reduce the human readability.
The big question is what do we want to do with cell-level security in the future? I think we probably want to support "not" at some point, so probably '!' and '~' should be reserved. If we do want to support escaping, we should probably reserve '\' or '#' and ';'. It has been hinted that we might want to support something like regular expressions, so '*', '?', '[', ']', '+', .... How about variable substitution, with '%' or '$'?
Maybe it would be better to keep a white list for now?