Question: When I delete rows from a table in SQL Server, the size of the database file does not get smaller. Why is that? Even if I delete every row from every table, the file size remains just as large as before the delete.

I'm interested in understanding why, not how to shrink the database file(s).

Answer: 
Space in database files is allocated as needed. When rows are removed from a table, that space is simply marked as unused inside the datafile. Datafiles do not shrink automatically (unless auto-shrink is turned on) because that requires extra disk I/O that is typically counter productive for performance. The assumption is that any unused space will at some point be re-used by new rows.

To summarize, space allocated to the file on disk, and the logical size of tables within the database are not tightly coupled.

In more detail (although still very simplified):

They are definitely related. Rows in a rowstore live on pages, which are 8k in size and arranged into extents. Extents are groupings of 8 contiguous pages on disk.

Rowstore rows lives on pages and when "deleted" are not physically removed from the file - just marked as "free" inside of SQL Server through the use of bitmap and bytemap allocation structures and SQL Server will re-use the space accordingly.
Think of SQL data files as a commercial self-storage unit:

[![row of self-storage doors](https://i.stack.imgur.com/vBFBg.jpg)](https://i.stack.imgur.com/vBFBg.jpg)

Data from tables and indexes is organized into these units (called "pages"), and SQL server is very meticulous about keeping track of what belongs where.

If you fill up all the storage units, you can buy land and build more (expanding the data file), but what happens when some units get emptied?

* If the empty unit is at the *end* of the row, sure, you *could* demolish the unit you built and sell off the land, but that's a lot of work, especially if you might need to buy it right back again.
* But if the empty unit is in the *middle* of the row of storage units, you *can't even do that* without a lot of extra work. You'd have to *move all the stuff from full units at the end of the row into the empty units in the middle* before demolishing units and selling off the property.

Not only is moving all those units around a lot of (unnecessary) work, it also can cause *table and index fragmentation*, which can impact performance. 

Imagine if you had a family that bought 10 units next to each other, and you later forced them to move 4 of those units to random empty units elsewhere in the facility. When they came to add or remove stuff from their units, they will have to do a lot of extra work wandering around between the scattered units.

Obviously this analogy isn't perfect, and clearly there are situations that you really *do* want to shrink a data file, but you don't want SQL server doing it on its own, you want to be in control of when and how exactly that happens. For example, you'd probably want to do a `DBCC SHRINKFILE` to a specific size, leaving some portion of internal free space, then follow immediately by a reindex/defrag of your tables/indexes, to fix any fragmentation you've just created.

Moral of this story: [**Never turn on AutoShrink!**](https://www.sqlskills.com/blogs/paul/auto-shrink-turn-it-off/)