HDD as abstraction layer doesn't need the concept of deleted data. It's a block device. You can either read or write to its block, a sector of your choice. Whatever you write to the sector, you can read it later as many times as you want. If you overwrite the sector then consecutive read attempts will return the new data. There is no special state that indicates "no data". If the sector size is 512 bytes and the disk is healthy, then you will get 512 bytes from it every time you read. Some higher abstraction layer needs to know whether these bytes mean something or not.
Usually a filesystem is such a layer. The same byte sequence returned from the same sector may be a part of some file or empty space, depending on contents of other sectors (in your example: where MFT is stored). The term "empty space" here is misleading; "expendable bytes" would be better.
Since any sector has to return some data anyway when queried, it's a sane and common approach to leave the data intact while deleting a file and modify just the metadata (e.g. MFT) which tracks meaningful and expendable sectors. Common filesystems handle deletions this way.
This separation of layers works very well with hard drives.
For SSDs (flash memory in general) there are at least two reasons you'd like to let the device itself (i.e. its firmware controller) know which sectors are expendable.
One is the fact that you cannot directly overwrite data stored in flash memory cells (frankly I'm not sure if this applies to all technologies, but it applies at least to some of them and they are common). You need to erase cells, and then write new data to them during a separate operation.
This means that internally there is a state indicating "deleted" or "no data". If the device knows which sectors are expendable, it can erase them beforehand and when the time comes to write something, there is no delay. (Well, it's even more complicated. You can erase no less than a whole bunch of cells, a lot more than one 512-byte sector. For more information research "flash blocks and pages", "flash garbage collection").
The other reason is wear-leveling. A flash memory cell wears a little with every write (or rather with every erase). If you keep overwriting the same logical sector again and again, your modern SSD will remap it to different physical cells so they use up evenly. The device probably has a significant pool of "spare" cells it can use even if none of the logical sectors is known to be expendable, but the whole trick works better if the controller knows which sectors contain data that is no longer needed, so it can freely reuse cells mapped to them.
When your operating system (that understands the filesystem) informs your SSD which sectors are expendable, we call this trimming (see this answer of mine for some details).
Note that even if the whole SSD is internally erased, any sector will return some binary data when read (I guess the firmware will probably return all zeros, I haven't tested though); you cannot tell erased cells from cells actually containing this particular data just by reading from the device. Externally this mimics the traditional HDD behavior where there is no concept of erased (deleted) data at all.