Actually, there's a bit of a distinction here - namely between whether something CAN be automated and whether it SHOULD be automated. Just about anything software does can be automated, but whether it should be is an entirely different matter.
For instance, if you're going to test whether a printout matches the on-screen display, the manual method is, more or less, print it, walk to the printer, get the printout, hold it up against the screen and eyeball it.
You could automate this: you could build a mechanical catch into the printer to detect when a page is printed (or a robot to move the page somewhere visible, depending on printer model), use a webcam to capture an image of the printed image, then use either fuzzy image comparison or OCR to validate the data in the printout. (I don't recall who it was, but someone did actually do this as proof-of-concept).
It's pretty obvious which method here is easiest and has most benefits.
Academics can and often will lean toward the theoretical approach that anything generated by software can be automated. Practising testers will usually lean toward the practical approach of not automating if it's going to take too long and be too fragile (I won't go into the robotic finger to test a pin pad or a biometric fingerprint reader). A rule of thumb is that the more things that have to be strung together to perform the test, the more fragile any automation of it will be.
The short answer is that yes, it is possible to have 100% automated coverage, but there are very few situations where you would want to have 100% coverage (I have to admit it would be rather amusing to have an automated test robot trundling around the test lab operating turnstiles, pinpads, and other devices. I just wouldn't want to be the one maintaining it.).