Answer is in the article you are referring to:
Here the planner has decided to use a two-step plan: the child plan
node visits an index to find the locations of rows matching the index
condition, and then the upper plan node actually fetches those rows
from the table itself.
Output here means physical read of values. Child plan does not read values, it only reads locations (addresses) of rows, then parent plan actually reads the values. And next sentence provides explanation why two step process is chosen:
Fetching rows separately is much more expensive than reading them
sequentially, but because not all the pages of the table have to be
visited, this is still cheaper than a sequential scan. (The reason for
using two plan levels is that the upper plan node sorts the row
locations identified by the index into physical order before reading
them, to minimize the cost of separate fetches. The "bitmap" mentioned
in the node names is the mechanism that does the sorting.)
Later in the text you'll find examples of two child processes where one process has
width=244 and the other
width=0. Usually child process will fetch row locations with 0 output, and then parent process actually output rows. It is not used always, but there are situations when it is faster than reading rows straight away.