I will try to be more specific. Youtube uses x264 to encode videos at a certain bitrate. Were you to encode the same video with libaom (AV1) at the same bitrate, the quality difference would probably be noticeable to a casual viewer. If you were to cut the bitrate in half and run the same comparison, the quality difference would be extremely noticeable to a casual viewer.

EDIT: Err, I'm stupid it says 30kbps right there. Though that definitely looks closer to 100 to me (unless framerate is lower)

For making encodes for personal use, HEVC/x265 is the clear choice today, and it probably will be for a long time.

If you want to use AV1/libaom and see significant efficiency gains over HEVC/x265, you will have to allocate a lot more encoding time. There's no way around that. You will also not be able to make use of multithreading to a significant degree, for libaom at least (I have not seriously tested other encoders). There are third-party programs in active development that perform chunked AV1 encoding for the purpose of utilizing all your cores.

aom --cpu-used=5 is currently strictly better than x265 --preset veryslow, putting aside the threading issue. Beats it in encoding time and efficiency. But it's an unfair comparison.

More info: https://www.videoproc.com/media-converter/av1-vs-hevc.htm

In theory the hardware vendors could notice that Google is developing a new codec which they could be reasonably expected to start using and then include hardware decoders in their devices before Google starts using it, but they don't really have the right incentives to do that. "Our device has a hardware decoder for a codec nobody is using" isn't really something customers buy phones based on. Meanwhile if the vendor doesn't put it in this year's model then they get to sell you a new phone with a hardware decoder next year after Google flips the switch and your battery life tanks until you buy the new phone.

And TV/STB SoC vendors like Amlogic, Broadcom or Realtek already announced products with AV1 support.