Diffie-Hellman is a key-exchange protocol. If two people want to exchange some encrypted information, they first need to share a secret key to do the encryption with. The problem is, they can't just send the key in plain-text, since any eavesdroppers would get the key too.
Diffie-Hellman gets around this by having each side share only part of a key, while keeping the other part secret. Both sides can then mix their own secret part with the other side's shared part to derive a common encryption key. An eavesdropper can't learn anything, though, since they only see the shared parts, not the critically-important secret parts.
The Diffie-Hellman algorithm comes in several different flavors. The current state-of-the-art is ECDH, which is fast and uses small keys. The problem is that ECDH only provides security against classical computers. If an eavesdropper has access to a big 256-bit quantum computer, they can work backwards from the shared parts to learn the encryption key.
Big quantum computers don't exist yet, but they might one day. Therefore, cryptographers are busily searching for alternatives to ECDH that don't have quantum weaknesses. We have some alternatives already, but they are either slow or require enormous keys.
This paper shows a way to do quantum-resistant Diffie-Hellman in a way that is significantly faster and smaller than anything we have see so far. It's still a lot slower than the best ECDH (~50 million vs ~50k cycles), and they keys are still a lot bigger (751 bytes vs 32 bytes), but it's still really impressive progress. Many of the alternatives have keys measured in KB or MB, which is obviously impractical.
48 bytes get expanded to 751. Whether you count this as 751 or 48 depends on what you want to compare.
Also, your description implies DH exchanges are zero knowledge exchanges - that there is no way to infer the private key from the public exchange - but that's not true. It is perfectly possible - in fact, in most DH variants a 1-1 transformation - except it is entirely infeasible.
Those 48 bytes are the two random numbers used as the private key, correct? The actual public key that gets sent over the wire is the 751 byte thing, if I read the paper correctly.
Isogenies are mappings between curves. So maybe one way to start getting your head around isogeny crypto is that you're dealing in higher-order curve structures.
You should see their (much faster!) subsequent paper. It develops an entirely new mapping to take advantage of Intel vector extensions, then invokes Valefor instead of Bael.
