If high efficiency wasn't touted as a feature then it would have been fine. But when it turns out that one of the main selling points is performance (with no expressed limitations or restrictions) and regular patterns perform badly, as a consequence of the design, then it is quite valid criticism. (Whether this is the case in practice I don't know but GP brings up a very valid point)
GPs point begs the question - Why was it designed in such as way? Quite possibly the tradeoffs were considered and the current solution was targeted because of several reasons. But the page doesn't convey any of that, it simply states that "In fact, it is one of the fastest packet sniffing and interpretation libraries available.".
While I agree with your point the library isn't exactly marketed as a lone wolf effort either, and that will also affect the criticism it will receive.
Heuristic construction of a packet filter based on previously seen exceptions is infeasible with the current API because rejection of the first N non-TCP packets does not guarantee rejection of the next one.
(rfind_pdu uses it internally: https://github.com/mfontanini/libtins/blob/37c92fcf5c83b034a...)
So for the cost of a few expensive frames at start, afterwards no exceptions get thrown.
Generally speaking though, I'm only replying because I hate people negging on minutia of new projects. If you're going to be critical of something especially when it's a lone wolf effort (or even a small team), try to be constructive, there are real people on the other end of the wire.