To explain it briefly though, choreographic programming is a method of writing distributed programs that communicate in some message-passing fashion by -- rather than writing separate programs that communicate with send/recv and must be very intentionally designed to be in sync -- you have /one/ unified messaging primitive. In a typical distributed system, you might have something like A.send_to(B) / B.recv_from(A). In a choreographic system, you'd rather have something like A ~> B, where send_to and recv_from are /projected/ from ~> into separate programs during the process of compilation.
You might want this kind of abstraction for various reasons, but the biggest is that many choreographic systems offer a guarantee of deadlock-freedom. This isn't without tradeoff. At the moment, choreographic systems (and session types, another distributed abstraction) are very bad at handling any kind of failure / degraded performance over the network. There is active work within the PL community on resolving these issues, but for now, choreographic programming is primarily useful for prototypes, rather than production systems.