For the first point, it works differently but the agent does (or can) update automatically. Instead of just updating the agent though the Operator itself deploys a new pod with the updated agent or you can specify a specific version that should be used. But using the operator does not mean you need to manually update agents.
See the section here with the example parameters at step 6. Auto updates are on by default but can be disabled: https://www.dynatrace.com/support/help/shortlink/openshift-manage-helm#installation
For point 2 that this is correct. Using the operator the agent gets deployed as a privileged container/pod and so all the limitations of monitoring from a container are still true.
The big motivation for the operator would be for 'day 2 operations' like if you had large or many clusters as well as it can do things like configure Istio to work with Dynatrace and other things can be added down the line.
In your case if you have a small cluster and you think you'd want to use any of the functionality that shows up as a limitation with the container based/operator approach I would just go with installation of a full OneAgent on those nodes. If down the line we do add functionality to the Operator that you would like to use it should be painless to swap over if it's a small cluster as well.
Lastly, not for you but for anyone else who comes across this, I just want to clarify for them that we're referring to deploying the OneAgent itself as a container, not the monitoring of containers.
