A strong answer
A sequential scan can be better when a query needs a large fraction of a table. It reads pages in order and avoids following an index to many scattered heap locations. An index scan is attractive when a predicate is selective enough that finding a small set of rows saves more work than traversing the index and fetching table pages.
The right choice depends on row distribution, table and index size, cache state, storage characteristics, row visibility, and the query's required columns. An index-only scan can avoid some heap visits when its requirements are met, but it is not automatic for every query.
The optimizer uses statistics and a cost model to estimate alternatives. I would inspect EXPLAIN, compare estimated rows with actual rows using EXPLAIN ANALYZE, and verify the workload before adding an index. Planner cost units are not wall-clock milliseconds, and ANALYZE executes the statement.
Follow-up direction
Use the PostgreSQL plan guide to walk through a concrete scan node and identify where its input rows come from.