Well, some testing shows me that _AreaThreshold doesn't do what I thought it did. I built a DB (no large file support), added a table to a new area, then added records to the area until _Areathreshold changed from 0 to 1. It never did. The DB just shut down when the variable extent hit 2 GB. So clearly, this VST doesn't tell you when the area HWM reaches 80% of the current total blocks in the area, nor does it tell you when the area has reached 80% of the maximum blocks possible in the area based on the existing structure.
The docs say that _Areathreshold = 1 means "Area is above 80 percent of maximum addressable threshold value". So I guess it's a comparison of _areastatus-totblocks to the theoretical maximum number of dbkeys in the area? If so, I'm not sure how useful that is when you have 64-bit dbkeys.
As per your screenshot, area 7 in database sop has eight extents totalling 14.58 GB on disk. This doesn't give us any indication of how full the extents are. Extent 8 could be almost full. Or if someone just purged the table(s) it could be completely empty.
I think the monitoring solution you're looking for will involve a join on _Area, _AreaExtent and _AreaStatus. _AreaStatus has the HWM and total blocks for each area, and _AreaExtent has size information for each extent in each area. I don't have any code at hand to do that, but I'll think about it if I get time.
Also, and I know I'm preaching to the converted here, based on area 7 alone this DB is really too big for the workgroup license. At this size the client should be on Enterprise, in which case 2 GB extents are no longer a concern.