Good, simple, basic terminology question.
Answer is correct.
Question text is a bit strange. Yes, we call a table with no clustered or nonclustered indexes a heap. But that name also applies to tables that do have nonclustered index. The only thing implied by the name heap is the absence of a clustered index.
The explanation is partly right (it does include the correct definition for heap), partly wrong and misleading.
* "Unindexed tables are good for fast storing of data." - I am not at all sure that heaps are better for this than clustered indexes. In fact, I am not even sure what the exact comparison is about. "fast storing of data" - surely that cannot be the only objective? If all you want to do is store and never retrieve, then you can just as well throw away the data right away. I am guessing (from context) that the intention was to write "fast insert performance". And it's true that if you need insert processing to be extremely fast, a heap will be better than a randomly chose clustered index - but it will not be faster than a clustered index on an always increasing key (like for instance date/time of insert, or an identity value). So there are still at least those two options, giving you the opportunity to optimize for other requirements as well. There may be cases where the heap is indeed the fastest - but they will be the minority, not the majority. Fragmentation can make heaps incredibly slow. Google "the table scan from hell" to see a simple example that shows a table scan that gets 12.5 x more expensive after updating just 25% of the rows in a table.
* "Many times it is better to drop all indexes from table and than do bulk of inserts and to restore those indexes after that." - For nonclustered indexes, this is true. If you need to make lots of changed to the table data (not just inserting, same goes for deleting or updating), then dropping or disabling the nonclustered indexes first, then recreating or rebuilding them after the changes are made can be faster - depending on the amount of change versus the size of the table. But that is only for NONclustered indexes. Definitely not for all indexes. I have never seen a case where you could gain performance by dropping a clustered index, then later rebuilding it. Dropping a clustered index has little overhead if you make sure to drop nonclustered indexes first (otherwise, all nonclustered indexes are basically rebuilt). But creating a clustered index has a lot of overhead: all data in the heap is read, sorted, and used to create a completely new copy of the table, after which the old one is deleted. Lot of reading, lot of processing, lot of writing. (And if you have any nonclustered indexes at that time, they too need to be rebuilt).
There are valid use cases for heaps. But there are not many of them. And they can be very challenging to properly maintain. As a rule of thumb, my advice is to steer clear of them, and only ever use them if you are 100% certain that you understand all implications, and that your specific situation does indeed call for a heap.