Actually boost.spirit is an excellent library. The fact that it can both parse and generate made it a great basis for the Io debugger I wrote that wraps gdb; since gdb uses a text based interface I had to both parse and generate in order to spoof gdb responses for Io script debugging. Spirit allows me to do that quite ncely.
Like anything boost spirit has a leaning curve. You could just as easily say no one should use emacs because it is hard to learn. In fact I personally don't use emacs because I found it too hard to get going with, but I don't from there extrapolate that no one else should use it.
The compile time and binary size problems of boost spirit can be addressed by factoring your grammar into smaller subgrammars in separate compilation units. The subgrammars can still be combined the same as rules can be.
The obscure error messages can be improved by using typeful programming so that you get an error like "no conversion from MyRuleADatatype to MyRuleBDatatype".
Yes these things are still problematic, but how do we get from "X is hard" to "no one should use X"? See the Clojure author's talk on Simple vs Easy: he lambasts programmer culture for being obsessed with 'easy' to the detriment of creating useful stuff. He asks, what if the Foo Fighters said guitars are hard to play, let's play kazoos because they are easy. Would you listen to the Kazoo Fighters, he asks.
For simple lexing/parsing it likely is overkill, that said for more complex things it can be nice. I have a lexer for Erlang written with Boost.Spirit on my Github. I found debugging no worse than the general Chutulu-horror that are C++ template errors, something you get used to, looking at the root of the spew is generally your best bet. Also they have built in debug nodes you can trivially add to your grammar that will spew every step of the lexing/parsing process so you can easily see where things are going off the rails if your grammar is wrong. Compile times are definitely increased in my experience, don't recall the binary bloat though it has been awhile since I played around with it, a good compiler should be able to fairly aggressively trim it down. Will it be as optimal as a hand written system (assuming you know what you are doing)? Unlikely, but it will be much quicker to get up and running if you know Boost.Spirit.
Like anything boost spirit has a leaning curve. You could just as easily say no one should use emacs because it is hard to learn. In fact I personally don't use emacs because I found it too hard to get going with, but I don't from there extrapolate that no one else should use it.
The compile time and binary size problems of boost spirit can be addressed by factoring your grammar into smaller subgrammars in separate compilation units. The subgrammars can still be combined the same as rules can be.
The obscure error messages can be improved by using typeful programming so that you get an error like "no conversion from MyRuleADatatype to MyRuleBDatatype".
Yes these things are still problematic, but how do we get from "X is hard" to "no one should use X"? See the Clojure author's talk on Simple vs Easy: he lambasts programmer culture for being obsessed with 'easy' to the detriment of creating useful stuff. He asks, what if the Foo Fighters said guitars are hard to play, let's play kazoos because they are easy. Would you listen to the Kazoo Fighters, he asks.