Why is the output of elliptic curve based cryptosystems smaller than for ordinary public key cryptosystems?
There are common Elliptic Curve Cryptography public-key cryptosystems which output is just as small as "ordinary" ones, if we take that as pre-ECC. Take for example Schnorr signature: even when based on arithmetic modulo a 16384-bit prime, it has a signature just as compact as its ECC equivalent: $3b$ or $4b$ bits for $b$-bit security (depending on if you want belt only, or belt and suspenders).
Let's now more precisely define "ordinary" asymmetric cryptosystems. Take these as those working in $\Bbb Z_n$ and assuming the difficulty of integer factorization of $n$ like RSA encryption and signature; or working in $\Bbb Z_p$ with $p$ prime and assuming the difficulty of the Discrete Logarithm Problem like the original ElGamal encryption or the aforementioned original Schnorr signature.
One way to justify why these "ordinary" cryptosystem require larger public keys and operands than ECC ones is: they operate directly using multiplication in a field.
This implies two internal laws (addition and multiplication) in the set, with the distributive property linking them. Contrast with Elliptic Curve Cryptography, which operates on a set (the points on the curve including the point at infinity) with a single well-defined operation between elements of the set: point addition. In turn, having a richer algebraic structure enables more algorithms.
That is most apparent when it comes to the Discrete Logarithm problem, which can be posed in the same terms in the two cases: for 128-bit security we need a field $\Bbb Z_p$ with like $2^{2560}$ elements when operating directly on it, because we have index calculus and other sub-exponential algorithms to solve it; when we can make ECC on a group with like $2^{256}$ elements, because only algorithms that work in a generic group, like Pollard's rho, seem to be applicable.
For the question from the standpoint of the size of ciphertext, see poncho's 's excellent answer.
The classic approach to solve that issue is hybrid encryption. In a nutshell: to send a large amount of data encrypted, draw a random secret key, and
- Encrypt it using an asymmetric cipher with the receiver's public key, and output that as the start of the ciphertext.
- Use that secret key (in the form before encryption) as the key to an efficient symmetric encryption (authenticated, preferably), e.g. Chacha-Poly1305 or AES-GCM-SIV, producing the rest of the ciphertext.
The receiver side gets the start of the ciphertext, deciphers it with it's private key, and now has the symmetric key. It proceeds with the decryption (and check) of the rest.
It's the best of both worlds. Everything does that: PGP, Whatsapp, younameit.