It's nice to see they've tried to work around the soft 404 problem in their docs, but it shouldn't be necessary. It's just another case of how Google has optimized out a use case that only developers rely on.
I've voiced similar complaints about how google parses my search query, but they seem to fall on deaf ears.
Google used to provide uncannily accurate results for such queries and apparently no one noticed when it was changed.
I'm an engineer at Google who worked on the query parser code in 2009 and 2010. I can assure you that at no point around then did punctuation like square brackets get used, inside or outside quotation marks. The results changing from results that suited your intent to results that didn't must have been caused by other changes to the ranking algorithm or the Web as a whole over those years that happened to be unlucky for you.
Punctuation is a huge challenge for us. We can't simply index all the punctuation on every web page on the internet -- think of the blowup of our index! Think how much slower our search pipeline would be! But we're working on it. Now we recognize some common punctuation uses cases like @ and #. Compare the search results for mattcutts vs. @mattcutts, or obama vs. #obama. We'll keep working on the other ones. The programming ones hinder us coders a lot too. :-)
You may search for things, but you probably overestimate the number of times you actually find anything relevant. Most of the time, you'll find a page about the exception class itself (fine; not very useful), or you'll repeat your search with something more specific, and get either nothing, or you'll get some blog post (or worse: forum question) talking about how someone once encountered an exception, without any relevant answer.
What we're trying to do here is make it possible for people to search for exception messages, and find the code where those exceptions actually get raised. It's something I've wanted for a while, personally.
Google aggressively tries to not show error and exception results as bad actors could potentially use them to attack a site. For example, if a particular error returned was indicative that a site wasn't safely handling SQL queries, etc.