The stock ELB health checks allow you to check raw TCP responses or go higher in the stack and look for an HTTP/200 response.

Either is good. A basic check should get you started but as your application and its dependencies evolve, you might need to enrich your health checks too.

Let us suppose that you were serving a web application that relies on a cache and a database backend.

If the ELB was checking TCP:80 then as long as your HTTP daemon is running, it will receive an OK. If you were checking for an HTTP/200, instead that would verify access to the application's file(s) on disk but likely not much more.

Instead, you could benefit much more from pointing the ELB at a dedicated health check endpoint within your application, which verifies all its dependencies (disk: OK, cache: OK, db: OK) before returning a green light. But beware of impacting the overall application performance: the more frequently the health check is called, the more lightweight it ought to be.