The question of "What is the purpose of introducing the untrusted "server" component?". Looks like you've since replied to this, but it wasn't here or I didn't see it when I dropped the parent comment. The reply also doesn't compare alternatives such as direct use of an object store API. I've fielded a lot of user support questions about installation and would really hesitate to add that extra moving part if it's not strictly necessary.
Overall, we must be coming at this with quite different expectations of what a NVR should do. Not just this but also "when the app fetches a video, the server deletes the ciphertext (in order to be memory efficient)". Some installations of my NVR software are multi-user; I personally use it from multiple devices; etc. So the idea the whole pipeline exists just to transfer event videos to a single Android device results in a system that I would not find useful.
There certainly is space for different approaches. E.g. Frigate's approach is quite different than Moonfire NVR's but obviously is useful in a lot of ways to a lot of people. But my take is that Privastead's approach is going to be pretty niche, and the claim that other NVRs don't offer strong privacy assurance using "end-to-end" (on-prem server to client) encryption is untrue.
Also, I find it inaccurate to say it's mostly implemented in Rust which "provides higher security assurance for the hub". The Amcrest camera you've chosen is essentially developed by a hostile nation-state, and the protocol code you're using to interact with it (ffmpeg) is all written in C, which I find incongruous with the privacy/security goals. In fact, ffmpeg's RTSP and Matroska code is probably the majority of lines of code in the system.