[scott_s]

Is it any scarier than having wildly inefficient software code? (Think a naive traversal of large matrices that thrashes the cache.)

That's a workflow where optimization requires knowing the internals and how they interact, but you can ignore such things if you just want correctness. At least in software, that model works well, because the performance of most of the code we write doesn't matter - even in applications where performance is a concern.

[mng2]

I wouldn't call it 'scary', myself, but it doesn't strike me as a particularly useful feature. In software, a single slow subroutine can simply take up more cycles. But in hardware, a slow path becomes your critical path, and you have a hard clock cycle requirement. (Sure, you can use multi-cycle paths and/or change clock speed, but those generally have to be adjusted manually/physically, and not all design situations will have that flexibility.)