Full Completeness vs Full Abstraction of a program translation
Unfortunately, there are too many things are going on here.  So, it is easy to mix things up.  The use of "full" in "full completeness" and "full abstraction" refer to completely different ideas of fullness.  But, there is also some vague connection between them.  So, this is going to be a complicated answer.

Full completeness:  "Sound and complete" is a property you want for a traditional logic to have with respect to its semantics.  Soundness means that whatever you can prove in the logic is true in the semantic model.  Completeness means that whatever is true in the semantic model is provable in the logic.  We say that a logic is sound and complete for a particular semantic model.  When we come to constructive logic, such as Martin-Lof type theory or linear logic, we care not only about whether formulas provable, but also what their proofs are.  A provable formula may have many proofs and a constructive logic wants to keep them apart.  So, a semantics for a constructive logic involves specifying not only whether a formula is true, but also some abstract semantic notion of "proof" ("evidence") for its truth.  Abramsky and colleagues coined the term "full completeness" to mean that the proofs in the logic can express all the semantic proofs in the model.  So, "full" refers to proofs here.  A "complete" logic can prove everything it needs to.  A "fully complete" logic has all the proofs that it needs to have.  So "full completeness" means "constructive completeness" or "proof completeness".  This has nothing to do with full abstraction.

Full abstraction: "Adequate and fully abstract" is a property you want for the semantic model of a programming language.  (Note the first difference: we are now dealing with the properties of the semantic model, not the properties of the language!)  Adequacy means that, whenever two terms have the same meaning in the semantic model, they are observationally equivalent in the programming language (with respect to some notion of execution).  Full abstraction means that, if two terms are observationally equivalent, they have the same meaning in the semantic model.  These ideas can be related to soundness and completeness, but in a somewhat contrived way.  If we think of the semantic model of a programming language as a "logic" or a "proof method" to talk about observational equivalence, then adequacy means that this proof method is sound; full abstraction means that this proof method is complete.  There is no notion of "full completeness" here because nobody has yet produced a semantic model that represents a constructive proof method.  (But, such a thing is theoretically possible, and one of these days somebody might do so.)

In your case, you are interested in translations rather than semantic models.  The properties of adequacy and full abstraction can be extended to deal with translations as follows.  You think of the target language as your "semantic model", i.e., a formalism that you fully understand somehow.  If so, you have some notion of equivalence for it.  Then, we say that the translation is adequate if, whenever the translations of two source programs are equivalent in the target language, they are observationally equivalent in the source language.  We say that it is fully abstract if, whenever two source programs are observationally equivalent in the source language, their translations are equivalent in the target language.

In reality, I don't know of any target languages that we really fully "understand".  All we know is some other notion of observational equivalence for the target language.  In that case, the translation is adequate if the observational equivalence of the translations in the target language implies observational equivalence in the source language.
$$ \tau(M) \cong \tau(N) \Longrightarrow M \cong N$$
The translation is fully abstract if the observational equivalence of the terms in the source language implies the observational equivalence of the translations in the target language.
$$M \cong N \Longrightarrow \tau(M) \cong \tau(N)$$
Some authors take "fully abstract translation" to mean the combination of these two properties:
$$M \cong N \iff \tau(M) \cong \tau(N)$$

Egger et al seem to be similarly extending the idea of full completeness to translations.  In their set-up, formulas are types and proofs are terms.  Their translation translates types as well as terms.  They call their translation fully complete if the translation of a type $A$ has only those terms that are obtained by translating the original terms of type $A$.
$$\forall N : \tau(A).\; \exists M : A.\, \tau(M) = N$$

Now for the vague connection between full completeness and full abstraction.  Proving that a semantic model or a translation is fully abstract often involves some of definability.  This is because our languages are generally higher-order.  So, if the semantic model or the target language has too many "contexts" then it will be able to poke our terms or semantic meanings in undesirable ways and spoil their equivalence.  "Undesirable ways" means in ways that the programming language itself cannot poke them.  So, to get full abstraction, we need to ensure that the "contexts" available in the semantic model or the target language do come from those in the source language in some form.  Note that this relates to the full completeness property.

Why do we want such properties?  It has nothing to do with compilers!  We want these properties in order to claim that the source language embeds into the target language.  If we are happy with a particular target language (as being clean, understandable, somehow fundamental or God-given) then, if the source language embeds into it, then we can claim that there is nothing new in the source language.  It is just a fragment of the target language that we know and love.  It is just syntactic sugar.  So, fully abstract translations are given by people to establish that particular target languages are great.  They are also sometimes given by people who have a big or complicated language to deal with.  So, instead of defining a semantics for it directly, they translate it to some core language and then give semantics to the core language.  For instance, the Haskell report does this.  But the full abstraction of these translations is rarely ever proved because the source languages are big and complicated.  People take it on faith that the translation is good.

Once again, this has nothing to do with compilers.  Compilers are rarely ever adequate or fully abstract.  And, they don't need to be!  All that a compiler needs to do is to preserve the execution behavior of complete programs.  The target language of a compiler is generally huge, which means that it has lots of contexts that can mess up equivalence.  So, equivalent programs in the source language are almost never contextually equivalent when compiled.