Columns count in SELECT query and SQL Server buffer cache
SQL Server stores all the columns for one row together in a single disk page.  (It's more complex than this but for int and char etc. this is more-or-less true.)  To retrieve any column's value the whole page is read into RAM.  So once you have any column available for a given row, all of the columns for that row are available.

There are several buffers / caches involved in responding to a query.  One is the great big page bufferpool where pages read from disk are held in memory so execution plans can act on them.  And yes, if one query causes a page to be loaded into the bufferpool all subsequent queries will use the same page from the bufferpool and not have to suffer the IO overhead.  This is an incidental performance gain, however, and shouldn't be relied upon because SQL Server may choose to evict any page from the bufferpool at any time it needs the space.

Another set of buffering occurs when the output from your query gets sent over your connection to your application.  This is (mostly) on a per-connetion basis so duplicating the work duplicates the resources required (more or less).

Another cost is the optimisations you miss out on when you return all columns.  Covering indexes and "INCLUDES" columns are meaningless.  Every read will have to retrieve the underlying clustered index (or heap) page.  It's a fair bet that SQL Server will not be using specific indexes it might otherwise have chosen because a scan-the-cluster plan is cheaper than an index-and-cluster plan.