For instance, in the book of Grune and Jacobs on parsing techniques, they are presented as essentially a curiosity (with 2.5 pages of description in a 600+ page book).
There is of course plenty of academic work specifically on how to implement parser combinator libraries efficiently, how to make them invertible (so they can also produce prettyprinters), provide good error messages, etc.
And that's why parsing research doesn't pay much attention to it - it's an interface, not a different approach to handling data while parsing. It's all about ergonomics of using a parser, not about the capability and performance characteristics of parsing.
Should more research pay attention to that? Probably. BISON/YACC/ANTLR are all hell to use. Combinator-based libraries are easier, but current designs lack things like extending parsers without modifying them. There's a lot of research that could be done that would care about this aspect of parsers, but it doesn't seem to be for now.
Also, higher-kinded types are pretty much required to make parser combinators nice, so that restricts the appeal of parser combinators to just Haskell and a few other niche languages.
Yet another reason is that like all recursive descent parsing with backtracking, it's easy to accidentally make your parser run in exponential time. It certainly requires discipline and deliberation to avoid that.
†: I only know of one library in Haskell that has a parser-combinator-like interface without recursive descent parsing, and that's https://github.com/ollef/Earley but I'll quote from its README the difference between that and typical parser combinators:
> The grammar language is similar to that of many parser combinators (Parsec, Attoparsec, parallel parsing processes, etc.), providing an applicative interface, but the parser gracefully handles all finite CFGs, including those with left-recursion. On the other hand, its productions are not monadic meaning that it does not support context-sensitive or infinite grammars, which are supported by many parser combinator libraries.
But really, otherwise there is not much to say about parser combinators, as they are just code. The cool thing about parsing is that usually you can give much nicer descriptions of the grammar than via parser combinators, and you can analyse these descriptions (uniqueness, for example), und generate optimised code.
There isn't much to cover about them, they are just very ergonomic. Even guaranteeing a good performance is covered on the theory of other types of parser, that is them trivial to replicate on them, but it's not about them.