"Need" is pretty strong phrasing. Let us be more specific and then you can determine whether you want to do this:
A heap isn't a linked list. I.e., SQL Server when it accesses a heap can either find the rows through a B-tree index or for a table scan use the IAM pages (a map of which extents the heap is using).
Shrink moves pages from end-of-file towards beginning of file (without regard to the order of pages for a linked list). For a linked list (a B-tree index), than can cause SQL Server to "jump back and forth" in the database file when it read lots of pages (a scan or partial scan). With spinning disks, this can be bad. Less bad with modern disk subsystems (which is why we focus less on defrag nowadays). This is what we call external fragmentation.
Since there's no concept of "following the linked list" for a heap, the consequence of shrink is close to none for a heap. Sure, the pages for a heap can end up more spread-out in the file compared to earlier. But we don't have the "jump back and forth" aspect for a heap. There are also details like SQL Server using scatter-gather I/O to minimize the effect of "spread" of data.
There are other things, like your pages might not be full (internal fragmentation) and forwarded records (a row was updated, moved to some other location and on the old location there's a pointer to the new location). This is not changed by shrink. Sure, it might be beneficial to do a rebuild, but these aspect were not changed by you doing a shrink.
I.e., short answer is: a shrink doesn't make a heap less efficient.
And, as already mentioned by David, you might want to not have these as heaps in the first place...