My typical go-to formula for the area of a triangle with vertices in nD is Heron's formula. Actually this is a formula for the area of a triangle given its side lengths. Presumably it's easy to compute side lengths in any dimension: e.g., a = sqrt((B-C).(B-C)).
Kahan showed that the vanilla Heron's formula is numerically poor if your (valid) triangle side lengths are given as floating point numbers. He improved this formula by sorting the side-lengths and carefully rearranging the terms in the formula to reduce roundoff.
However, if you're vertices don't actually live in R^n but rather F^n where F is the fixed precision floating-point grid, then computing side lengths will in general incur some roundoff error. And it may so happen (and it does so happen) that this roundoff error invalidates the triangle side lengths. Here, invalid means that the side lengths don't obey the triangle inequality. This might happen for nearly degenerate (zero area) triangles: one (floating point) side length ends up longer than the sum of the others. Kahan provides an assertion to check for this, but there's no proposed remedy that I could find. One could just declare that these edge-lengths must of come from a zero-area triangle. But returning zero might let the user happily work with very nonsensical triangle side lengths in other contexts not coming from an embedded triangle. You could have two versions: one for "known embeddings" (with assertions off and returning 0) and one for "intrinsic/metric only" (with assertions on and returning NaN). Or you could try to fudge in an epsilon a nd hope you choose it above the roundoff error threshold but below the tolerance for perceived "nonsense". These are messy solutions.
An open question (open in the personal sense of "I don't know the answer") is what is the most robust way to compute triangle area in nD with floating point vertex positions. A possible answer might be: compute the darn floating point edge lengths, use Kahan's algorithm and replace NaNs with zeros. That seems unlikely to me because (as far as I can tell) there are 4 sqrt calls, major sources of floating point error.
Re-reading Shewchuk's robustness notes, I saw his formula for triangle area for points A,B,C in 3D:
Area3D(A,B,C) = sqrt( Area2D(Axy,Bxy,Cxy)^2 + Area2D(Ayz,Byz,Cyz)^2 + Area2D(Azx,Bzx,Czx)^2 ) / 2
where Area2D(A,B,C) is computed as the determinant of [[A;B;C] 1]. This formula reduces the problem of computing 3D triangle area into computing 2D triangle area on the "shadows" (projections) of the triangle on each axis-aligned plane. This lead me to think of a natural generalization to nD:
AreaND(A,B,C) = sqrt( ∑_{i<j} ( Area2D(Aij,Bij,Cij)^2 ) / 2
This formula computes the area of the shadow on all (N choose 2) axis-aligned planes. Since the sqrt receives a sum of squares as in argument there's no risk of getting a NaN. There's a clear drawback that this formula is O(N^2) vs Heron's/Kahan's O(N).