I think the biggest impacts will be on the public relations side.
On the plus side (from OpenBSD maintainers point of view), the idea that the FBI deemed OpenBSD important enough, back in 2000, to warrant money-backed insertion of backdoors, is a sure ego inflater. This alone could be a motive for public allegations of backdoors, whether they exist or not. Also, the apparent immediate and full disclosure is a nice PR job.
On the minus side, OpenBSD communication has long been about how much more secure OpenBSD was than any other system, thanks to proactive security auditing and numerous internal code reviews. Finding a ten-year old backdoor right in the middle of cryptographic network code would kind of deflate the myth a bit.
Now, on the technical side...
There are many ways a subtle alteration of the code could constitute a "backdoor". If I were to implement a backdoor myself, I would try to rig the pseudo-random number generator. It is relatively easy to make a PRNG look like it produces cryptographic-quality output, but with, in reality, low internal entropy (e.g. 40 bits). This would make IPsec-protected communications vulnerable to decryption with common hardware and a passive-only attacker (thus undetectable). Also, a flawed PRNG can be attributed to incompetence (because making a bad PRNG is easy, but making a good one is not), opening the road to plausible deniability.
Another backdooring method is data leakage. For instance, whenever you have some random bits in some network packet, you can arrange for these bits to actually contain data about the internal system state. A good backdoor can thus leak secret encryption keys, to be picked up by anybody aware of the existence of the leakage.
Potential buffer overflows are crude backdoors, since they can be exploited only by active attackers, which is risky. Spy agencies usually abhor risks. If such bugs are found in OpenBSD code, I think it is safe to state that they are "true" bugs, not malicious holes.