I think the consistent rule here is that a reference may be used for a by-reference passed parameter. A pointer is used either for a passed parameter that is optional, or for a call-by-return parameter. There may be inconsistencies in this rule however the examples you show follow it. WaitForEvents' event list is non-optional (it may be in the C API, but it would be meaningless to not pass events), enqueueNDRangeKernel's event list is optional, Context's device list is an input parameter, not an output parameter getDevices is an output parameter. You briefly concerned me that Context's constructor might not be right because the parameter is non-const, but in fact it is a const reference:
Context(
const VECTOR_CLASS<Device>& devices,
As for your other question, All entities through the cl API are pass-by-reference. The reason you don't see it is that what you are really doing is passing a handle by value, but the handle of course is a reference to a runtime object.
The reason for a difference in C++ is that even the C++ wrapper objects are simply zero overhead wrappers for those handles. To improve safety of API use these wrappers are not zero overhead in execution because they reference count the handle by automatically handling retain/release calls that many programmers use inappropriately in the OpenCL API simply because getting it right is a pain. So there are circumstances where you don't actually want to reference count because there is overhead to doing that. Copy buffer operations should not reference count each buffer by copy on entry and exit from the function, because they are not really making a copy - the entity that was used on entry is assumed to still be around in the calling thread. Enqueuing the copy operation will ref count inside the runtime anyway as clearly we cannot delete a buffer while we are copying from or to it.
We are going through the process of significantly improving the documentation of cl.hpp, which should help.
