It greatly depends on what you do. For example, I have spent last hour reading HN, and visited dozens of different websites. None of them needed cookies at all, except HN itself (for user login).
A cookie could store the session id from a load balancer or app server, designed to beneficially route your return traffic back to the same warm appserver to reduce disk load times or whatnot. Blocking that cookie has no observable benefit/drawback to you, but possibly impacts the backend in a negative manner by triggering a fresh session on every visit/hit.
So, good for the user, who can't know what its session tracking cookie is used for, but bad for the server, who will have to come up with a better routing-and-whatnot scheme than relying on the user to willingly provide information they have a very real incentive not to provide.
Comments
It greatly depends on what you do. For example, I have spent last hour reading HN, and visited dozens of different websites. None of them needed cookies at all, except HN itself (for user login).
A cookie could store the session id from a load balancer or app server, designed to beneficially route your return traffic back to the same warm appserver to reduce disk load times or whatnot. Blocking that cookie has no observable benefit/drawback to you, but possibly impacts the backend in a negative manner by triggering a fresh session on every visit/hit.
These two are not mutually exclusive. The exact same cookie used for logging can also be used to store your session id for internal routing.
So, good for the user, who can't know what its session tracking cookie is used for, but bad for the server, who will have to come up with a better routing-and-whatnot scheme than relying on the user to willingly provide information they have a very real incentive not to provide.