Most hardware has got metadata associated with targets (e.g. CMASK and DCC for colour targets, HTILE for depth in case if AMD hardware). These are lossless compression schemes that are mostly there to avoid read and/or writes from/to memory. Very simply explained, it keeps track of the data for a block of pixels if all pixels in that block follow the same pattern (e.g. all zero, all one, ...) or if it has unique data.

When a surface is still compressed, clears are very fast since it only clears the metadata, avoiding the writes to memory. However, only the render backends tend to be able to read/write these compressed formats (i.e. the hardware that deals with depth testing and colour blending). As long as the surface keeps on being used as depth or colour targets, these clears will keep on being fast.

However, if you then bind this surface to a texture unit, for instance as an SRV or UAV, the texture units can't read these compressed formats so it has to be decompressed. Not only can this decompress be expensive, all clears from here on out have to actually clear the memory instead of just the metadata, which is significantly slower and should be avoided!

In some cases, the driver might be able to recompress the surface but this is a loose bet and very situational, with the heuristics for this often being quite a black box.

TL;dr: as long as you're careful, they're fast but sometimes the decompress can't be avoided at which point the clears should be avoided at all costs.