If you have an all-flash array, then auto-tiering using FabricPool to StorageGRID (or a 3rd party object store) is an awesome solution. Based on how much inactive data you have, you can easily reduce your cost per TB by half and your users may not even notice that you're doing it.
FabricPool is not available for non-SSD aggregates.
We're extremely satisfied with our FabricPool/StorageGRID implementation.
The main objective of Quality of Service (QoS) is to ensure "consistent" storage performance in a multi-tenant (Where multiple workloads share a limited resource) infrastructure. However, with 'Tiering' storage system applies predictive algorithm (active/non-active blocks) to shuttle data between different "media(SSD/SAS/SATA)" to reduces the "storage footprint" and the associated costs on high-performance SSDs.
I suppose, both are independent technologies and one has to be very watchful about which 'volumes' you are choosing for 'Tiering' purpose and which ones are "business critical" and you want to just stick to QoS. Overall, I think the combination of 'QoS' and 'Tiering' can help build you a very robust and consistent performance model.
I came across this - "Quality of Service Minimums & FabricPool are mutually exclusive": FabricPool and quality of service minimums (QoS Min) goals are mutually exclusive; QoS Min provides performance minimums, whereas FabricPool sends blocks to an object store—decreasing performance. QoS Min must be turned off on volumes in FabricPool local tiers. Alternatively, tiering must be turned off (-tiering-policy none) on volumes that need QoS Min.