How does sending compressed points in ECC can limit the attacker's capabilities? While sending an EC point we mainly have two options, send it compressed or uncompressed. The uncompressed has prefix 04 and compressed has 02 or 03 which indicates which $y$ to choose. Actually, it is costly, first find the $y$ and $-y$ from the curve equation;
$$E(K): y^2=x^3+ax+b$$ a cube and a square root is required. If the base field is prime then select according to the last bit of $y$ or $-y$. Select the one with 0 if 02 is encoded and select the one with 1 if 03 is encoded.
For 32-byte coordinates, this can save 31-byte of message size ( one byte increased, we send 65 for uncompressed due to prefix). If we consider the cost, it increases the computation, and sending 64-bye instead of 33-byte is not really a huge issue.
Now, Bernstein in their slides mentions that

Never send uncompressed $(x; y)$. Design protocols to compress one coordinate down to $1$ bit, or $0$ bits! Drastically limits possibilities for attacker to choose points.

How does sending compressed points in ECC can limit the attacker's capabilities?
If the implementation is using uncompressed point exchange, The attacker gets an opportunity to supply points to Bob that are not in the Curve which was selected by Alice and Bob. The attacker will supply points to Bob that are in curves of a lower order which makes it possible to estimate Bobs secret.
Therefore if the implementation ensures that Bob has to calculate the point then he will come to know that the point being provided is not on the curve selected by Alice and Bob in the first place and will result in coming to know about the attack or the corruption.
Two basic constructs in ECC are the standard curves and Implementation by programmers. The argument is should use of compression be specified in the standard or should be left to the implementation. Since compression is so important for ensuring security it should be made part of the standard( As per the presenters ) to prevent implementation errors.