Yacc et al are mainly useful for texts that do not fit the regular grammar. GFF/VCF/SAM can be parsed with regular expressions alone. More permissive grammars are not necessary.
I used to use flex/yacc in my early days in bioinformatics, but at the end of day, I think it is overkilling. EDIT: as to performance/flexibility, gcc switched from yacc to a hand-written C/C++ parser. If you really know what you are doing, hand-written parsers will be faster.
A little background on the theory of regex, yacc, context-free grammars, regex engine, DFA and their applications in computational biology. The following is poor-man's description. Not precise at all.
Formal grammar is the foundation of compilation theory in computer science and Chomsky hierarchy is the typical classification of formal grammars. In this hierarchy, regular grammar is the simplest but the least powerful grammar. Regex can be straightforwardly converted to NFA and then transformed to a DFA. Parsing is guaranteed to be done in linear time. A major limitation of regular grammar is that it ignores long-range correlation. For example, we cannot use regex to require matching unknown number of parentheses. Because of this limitation, the Newick format and HTML are not regular and cannot be parsed with a single regex.
Context-free grammar allows long-range interaction and is thus more powerful. According to wiki, it is "the theoretical basis for the syntax of most programming languages". However, this grammar cannot always be parsed in linear time and may require large memory to hold the entire parse tree. Parser generators usually implement a subset of this grammar that is simpler and more efficient. The LALR(1) grammar is such a subset, which yacc implements. IIRC, LALR(1) can be turned into a DFA. Parsing is achieved with a linear scan of the text with trivial memory footprint.
NFA and DFA are closely related to a Markov chain where each directed edge in the chain is associated with a symbol or token. Markov chain is somewhat the stochastic version of NFA. The stochastic version of context-free grammar (i.e. stochastic context-free grammar) has also been widely used for identifying RNA secondary structure and RNA alignment. It is also possible to describe some phylogenetic tree algorithms with the context-free grammar.
Now about regex engines. As is stated above, regex parsing can be done in linear time with the regex-NFA-DFA transformation. Implementing a DFA engine is non-trivial and frequently the limitation of regex is hurting. As a result, many popular regex engines are implemented with backtracking. A backtracking regex engine is easier to implement (requiring to up to 10-fold less code than a DFA regex engine), more flexible and is usually faster for simple patterns. The popular Perl regex and PCRE are using such an algorithm. However, a backtracking regex engine does not guarantee linear-time parsing. When you use a bad regex, it can be tens to hundreds of times slower than a DFA engine (for more discussions, see Russ Cox's article on PCRE vs. RE2). In my view, the worst-time time complexity is a far more significant concern than simplicity. That is why I said in the comment that we should drop Perl/PCRE for good: Perl/PCRE populated a bad algorithm for overcomplicated augment to regex, which misled programmers to think regex can be inefficient.
Back to the OP's question, most TAB-delimited bioinformatic format are regular. Going into more powerful but more complex grammars is unnecessary and inefficient. In my opinion, we should avoid non-regular formats unless necessary.
If you know what you are doing, handwritten code is always faster. The questions are: Do we know what we are doing (most often we are no experts of the problem)? Is the performance gain worth the effort?
To clarify, by "hand-written" I meant to use either regex or basic string routines (just do not use yacc). With regex, you need less effort for better performance. With basic string routines, you do need more effort, but you can save hours when parsing huge files. After all, if you do not know something, why not learn it? To me, yacc is harder to learn than regex and proper use of string routines?
I do agree with simple parsers (VCF, json, newick, etc.. ) but when I've have to handle ambiguity, states, complexity, lookaheads, etc... I still prefer to use a code generator :-) . It's easier to maintain the code with lex/javacc too.
regexp matching can be deceiving - I remember once writing a seemingly trivial HTML regex parser that would occasionally run stupendously slowly, like orders of magnitude slower than expected even though the input was just slightly different, may be just another wrapping tag or something similar. Back then I did not know about the worst case scenarios for backtracking type of RE engines and I spent a day or more debugging and it was eye opening to understand what happened. Of course when someone knows about these it is easy to avoid/recognize and for simple rules one would not even need to do that in the first place.
Moreover I will admit even today I have no idea that on how to optimize them, what makes a faster or slower construct and I will also admit to having a hard time understanding regular expressions that other people write. It is true that I don't make use of them that frequently and my eyes perhaps are not trained to read them. Just some personal observations on regular expressions.
Chuck Norris can parse HTML with regex http://stackoverflow.com/a/1732454/58082
On regex, I think we should abandon PCRE. It ruins the reputation of regex, IMO. RE2 in C++ is a much better library. In C, there is regexp9 from plan9 (you can find the regexp9.{h,c} somewhere in my github). With a proper regex engine, you do not need to worry too much about inefficient regex.