If it's just logs then it makes more sense to follow standard approaches and ensure the containers send their logs to standard output to integrate with both the standard Container Runtime and Kubernetes logging architectures, or forward them with something like our existing Fluent Bit solution.
Adding a whole persistence approach just for the sake of getting to logs seems the wrong way to approach the problem. It introduces extra complexity to the overall solution as we have to manage an extra combination of supported platforms with or without persistence.
Now we have the logs in a PV but then we need to go get them out of it using another bespoke approach rather than just deploying one of the many logging solutions that will pick them up from the CRI. I imagine a customer would prefer logs all work with the same tooling and it would also prevent losing information due to log rotation.