This question has more to do with the server implementation, and OPC UA specifications, rather than with QuickOPC, or the specific programming model(s) you choose to access your data.

First, the server must be able to do what you are asking for. No physical system can provide data in an infinite speed - there will always be limitations. Consult the server documentation or contact the vendor to see how fast the data can be obtained. The SamplingInterval should be set accordingly.

Second, it would be good if you have a look at OPC UA specs for details on how the data change notifications are transferred from the server to the client. It is a large topic, so I cannot describe it all here. You can start with Part 4 of the spec (Services), and have a look at the introductory parts to the "MonitoredItem Service Set". Concepts like sampling, filters, queues are described there. But I think one crucial element to consider is to set a non-zero QueueSize in the MonitoringParameters. This way, the server could queue the changes for some time, even if they are not sent to the client. And the client will then be able receive a bunch of changes in one message, and notify you about them sequentially.

Settings of parameters like MonitoringParameters.QueueSize is available in all the models we have (Procedural Coding/Live Mapping/Live Binding/Reactive Programming). In this sense, it does not matter which one you pick - if one can do it, others can do as well, and vice versa.

By OPC UA events, you probably mean OPC Alarms and Conditions (Part 9 of the spec). I do not think that can help here, because a) there will have to be a server-side support fore them, and b) they have different purpose anyway.

Also, I would expect the PublishingInterval be shorter than the SamplingInterval. When it is longer, and the QueueSize is 0 or 1, it is no wonder that some collected data get lost.

Best regards