As someone who designed a UI graphics stack almost from scratch, making a non-laggy UI has to be done from day 1, working with the EE's all the way up to the top most software stack.

It is hard, and any misteps along the way can doom everything. A single bus without enough bandwidth, not reserving enough CPU time for UI code, to not ensuring end to end performance of the touch system, any mistake and the UI will be sub-par.

The UX also needs to be informed by the hardware capabilities. Even simple things like whitespace around elements being scrolled can reduce HW load.

Honestly the animations don't look too bad, their touch layer however, it looks rather questionable. Doing touch right is a difficult task, it has taken modern smartphone platforms years to get latency down to where it is just barely visible. Now days early gesture recognition involves some amount of ML training that will a touch gesture recognizer that runs on the device, the recognizer is customized per model of touch panel/sensors. (Alternatively, one piece chips that do all of this for you exist, popping out already recognized gestures, they may or may not give better results, I haven't poked around in this space for a few years.)

On top of that, the touch panel needs to be running at a high enough refresh rate, and the entire UI needs to prioritize touch events over almost everything else! Audio Output > Video Playback > Touch Events == UI Updates > Rest of the world

Last system I worked on, touch events could be delivered to the UI up until the moment painting started, painting was capped at ~20ms (IIRC), running at 30fps.

The worst edge case saw 2 frames of latency before the UI responded. Average was around 1 frame of latency.

The other thing I'd have recommended they do for a v1 product is v-sync at 30FPS, and base everything off of that. A smooth 30fps is better than dropping frames at 60fps.

Treat it like a video game, you have a CPU budget in which everything must get done. The rest of the system must be running at a low enough CPU load that the render target can be hit every single frame.

But again, this all has to be started at day 1.