The biggest caveat to liberal use of reserved characters in URIs stems from bad parsers in the wild, or good parsers that don't have enough information to decide what to do. Since it's usually in your interest to make these identifiers available, it pays to make it so computers can read them without any trouble.
URI parsers and extraction heuristics are all over the place — most notably in e-mail programs, terminal programs and search engine robots, and they are not created equal. In this case, characters notorious for being missed by these parsers are the asterisk *, the comma , and the dollar sign $. Although most modern parsers are reasonably good, stragglers doubtlessly exist and testing should be done to avoid potential annoyances.
The second case is a bit more subtle. After a general delimiter has appeared in its rightful place within a URI, it may be used unescaped with relative impunity, otherwise it will usurp the URI with its own meaning. For example, the colon character : delineates the scheme or the port, and the question mark ? begins the query.
The problem arises when you have a relative URI reference embedded in a document, where a base URI is known to be set. For example, suppose you have a construct like http://example.com/path/foo:bogus and the base is set (potentially automatically, say through a CMS) to http://example.com/path/. Then in a link somewhere in the document, you have an automatically-generated relative URI foo:bogus. Oops. Your browser is probably going to think that's an absolute URI under the nonexistent foo: scheme.
The CGI specification defines the plus sign + as a parameter separator, which is largely interpreted as a space character. It is up to the application, however, to make this distinction. Bear this in mind if you want to represent a literal plus sign in a URI.
Finally, brackets and parentheses [ ] ( ) should be avoided because they balance, which opens a Pandora's box on the implementation side when some programmer invariably tries to do something clever with them. The problem with balancing characters is that they require a more sophisticated parser than a regular expression to be handled correctly, which is unduly complicated for something like a URI. In this case it is just best to forbid them in the interface specification, citing this reason. It is not the experience your organization's programmers in question, but those of other organizations who may consume your data.