I haven't been playing the game forever; I joined in with the OB along with some friends. For reference as to where I'm coming from here, I've got a QA background, including some professional, paid years as a QA guy for some LARGE game companies. Boy am I glad I don't do THAT anymore.
First up: I have no real first-hand knowledge of how Cryptic's engine really works. I have lots of conjecture and observational evidence, but I've never seen so much as a line of source.
Getting that out of the way: It seems evident that there are plentiful issues remaining (as is always the case with a newly-launched MMO) and many of these issues scream for attention from various users. I'm raising some points about 'misfires' and what I (think) the cause is.
To lay things out, we're all familiar with 'rubberbanding', where you'll be walking/running or flying your ship and then you'll get jerked back and spring forward. I am fairly certain this is caused by the way the game handles discrepancies between the server state and the client state, and the way latency makes this handling obvious.
The client keeps doing what you tell it (run forward, turn left, etc) and at regular intervals it updates the server and receives confirmation of what's been done. When these things don't agree it seems like the server state is the 'trusted' state. It's the least advantageous assumption to make for the player and results in the greatest immediate inconvenience, but it also prevents a hacked client or third party memory editor from allowing cheats (such as instantly changing ship-facing to protect a shield in combat, even in a Tier 4 cruiser, or perhaps instantly moving from one end of a sector space zone to another instantly). Some degree of 'distrust' for the client state is required for a sane game that wasn't to keep cheating and exploiting of this nature in check.
This is what brings us to our problem. Frequently in ground combat (since auto-fire seems to be gone there) we're mashing buttons to get our next shot off as quickly as possible. If the ability is on cooldown, the keypress/click is rejected. However, it looks like what happens is that it is possible to execute the action as soon as the client believes the cooldown is finished, causing the client to send a 'fire phaser rifle' command to the server AND kicking off the 'phaser rifle was just fired' cooldown. The result of this is the appearance of firing (character lifts the rifle and goes through the animation) combined with the expected cooldown. However, due to latency issues, it's possible that the server rejects this message (Hey, that ability isn't off cooldown! Try again when the cooldown is actually finished, cowboy!), and so no beam/bolt appears and no damage is done. This is a minor but frustrating annoyance.
When the same thing happens with longer-cooldown abilities it's next best thing to crippling; I have witnessed this behavior with Quantum mines (16s cooldown), High Yield I (45s cooldown) and other abilities, sometimes simple torpedo launches or uses of Science Team or Engineering Team.
The solution to the symptom is enhancing infrastructure and throughput so that there's no lag. (Or effectively no lag.) In these situations, the symptom (cooldown restarted, ability not activated) is very rare.
The solution to the problem is a change to (what I perceive as and guess is) the way the engine handles ability activations and client/server states. The simplest (conceptually) of these fixes would be to have the client cooldown updated when the server sends back a 'Rejected, not cooled down yet' response. Of course, the reality of it is, looking at the behavior of the client in the wild, it's an open communications cycle and the loop isn't ever closed. Client sends the 'execute' command and assumes it's done. The server rejects the command and nothing is done, but the client is never informed.
Either way it sucks when my mines have a 32s cooldown or my plasma pistol's exploit cooldown doubles while I don't manage to actually get a shot off on the exposed Reman...