I believe there is some need for method invocations/function calls (depending on what paradigm you are working within) to be programmatically accessible as objects, even in an unmanaged language. One important reason is debugging support.
Consider the situation where your code is a framework or middle layer that calls client code at the request of other client code. Sometimes a failure of some kind will occur in your code, not due to a fault in your code, but because the client code didn't follow the rules. While it is considered good programming practice in managed code to make your code robust against this situation, in unmanaged code, practical experience has shown that 1) this is not always possible, and 2) even when possible, this is not always a good idea because you will often lose valuable debugging information. Anyway, without getting too far off topic, suffice it to say that for certain types of code, it is not rare for a failure in your code to be the fault of someone else's code. In such a case, debugging support is a worthwhile nonfunctional requirement.
If you are aware of particular things that client code can do wrong that will make such-and-such a function in your code fail, it can be tremendously helpful, both to support personnel and also to developers of client code, to provide a debugger extension that analyzes the problem and figures out more specifically what is the likely ultimate cause. This may require looking at local variables in your function, the call stack, or other data specific to the function call.
