Few people asked "why duplicate v4l2 functionality", but really libcamera serves a different purpose. V4l2 (and v4l) are frameworks that support connecting multiple types of devices. IMO the biggest advantage of libcamera is their goal to abstract various camera controls (ISP profiles and on-camera registers) that are painful to use with v4l2. It complements v4l2, not replaces it

For example v4l2 has an ioctl to send raw read/write commands to a camera module. Having a datasheet one can then check which registers do what and one can set various features, but this requires using different registers and values for different camera modules.

Then we have ISP controls that v4l2 doesn't touch at all and to let's say change color correction, or automatic gain or autofocus one has to use (usually proprietary) tools from the Soc manufacturer. Some of those tools are open source and very powerful (on rockchip for example), but still developing apps one has to use a completely different method to adjust a rockchip's ISP vs let's say raspberry pi's.

So libcamera is a great idea to abstract all those hardware interfaces. Last time I checked they supported raspberry pi, and had a very minimal rockchip support.

Imagine there is a time when libcamera supports all kinds of Soc ISPs (rockchip, broadcom, allwinner, hisilicon and many others). Traditionally getting a directly connected camera to work (under mainline Linux) has been quite difficult on various embedded devices. Then getting hardware encoding to work is the second hurdle. Most often manufacturers distribute sdk's with their proprietary binary blobs built against ancient Linux kernels and one has to live with it if one wants to reuse various cheap Ip camera boards.