when it's ended up being a business necessity to 'erm wriggle through them in a less than gentlemanly fashion.
The thing is, those holes are not some omission in the framework, they are part of it, concepts like interfacing and aggregation etc, are a flimsy patch for the hole. Sort of like bunting, or a sign saying subsidence.

If you look at the .net framework code, Borland's VCL code, and I daresay all other written in these variants, the designers will have made use of the holes, to enable functionality at a lower cost, and often in scaffolding.

An absolute classic is say accessing a private member variable of a class in static method from an instance of it.
e;g
Public MyClass
{
private int _myField;
public int MyField {get {return _myfield;}}
public static DoSomething(MyClass argInstance, int argValue)
{
argInstance._myField = argValue;
}
}

Very useful hole on occasion that, when you want to expose an internal but give it a figleaf to avoid severe blushing.

If you go down the FP route it's apples and oranges time, that particular hole can't be there. Closing it, in a language where it does exist, would mean it would be a different language altogther.

I tend to think of them as tunnels as much as I do holes.