Nondeterministic automata can have far fewer states, but the engine to evaluate them must be capable of being in multiple states at once - all possible states. This can lead to a trade-off between memory requirements and code complexity when executing the automaton.
Personally, though, I think the more interesting issues relate to how you manipulate the automata themselves.
A DFA can be considered a special-case NFA - IOW you can define NFA to mean potentially (but not necessarily) non-deterministic.
Even with DFA, there are many possible equivalent automata that will give the same behaviour. But there is only one minimal DFA with that behaviour. This gives a canonical form for both a family of DFAs and for a (much larger) set of NFAs. But even when defining the canonical form for all equivalent NFAs, you must use a minimal canonical deterministic automaton.
In coding terms, there is more to defining a canonical DFA than just minimisation - you also need a canonical representation. However, using normal minimisation algorithms, these issues tend to resolve themselves in my experience, basically because the minimisation code is deterministic itself.
Once you have a canonical form of an automaton, you can derive a hash, or can do ordered comparisons - you can use automata as keys into data structures.
In theory, all NFAs have equivalent DFAs. In practice, extra information encoded in the model (outside of formal language/finite automata theory) such as annotations on states may mean that some NFAs have no equivalent DFAs - they are inherently nondeterministic. In my experience, eliminating all non-determinism that can be eliminated (with a variant of the subset construction), combined with some extra cleanups and minimization, still seems sufficient to give canonical forms, though I never formally proved that.
Also, there is no unique minimal equivalent automata - only a unique equivalent deterministic automata (or as-deterministic-as-possible with state annotations). An equivalent NFA to that minimal DFA may well be much smaller, but there is not (in general) one unique smallest equivalent NFA.
So working with DFAs is tempting because there is always one well-defined canonical result. If your goal is small automata, it's nice to have a clear definition of "smallest" and to always know that you're achieving it.
Using NFAs, you lose that nice "this-is-the-one-best-result" feeling. You have to make do with "small" rather than "smallest". You may get different automata where you expect equivalent results, and not be confident that they are in fact equivalent. But a typical "small" NFA may be much smaller than its "smallest" equivalent DFA, so that superlative may well be a red herring.
I think of it a bit like approximation algorithms. Do I need the "perfect" result? Though in this case, the NFA result is still (in behaviour terms) perfect. Only the representation loses the "perfect" label, and even then, labelling the minimal DFA as "perfect" only works because you're ignoring the potentially better NFA representations.
Anyway, when working with NFAs, the choice of representations for the results is basically heuristic. There are obviously well know methods for manipulating NFAs (the "partial derivatives of regular expressions" approach is one, though I'm not that familiar with these myself - derivatives of regular expressions (without the "partial" are an earlier method for not-necessarily-minimal DFAs).
DFAs are tempting because you can avoid that subjective grey-area. But I'm quite confident that this temptation should be treated with suspicion - because I fell into this trap myself :-(
In fairness, the DFAs I deal with aren't that big. But having a few thousand states where intuitively I was expecting a few dozen happens a lot - and that doesn't count all the states generated and discarded for intermediate results. I've survived this relatively unscathed, but with much more respect for the term "exponential growth".