I like the idea a little bit. Mostly because I don't like javascript. So I say keep going for it, it could fill some niches.
I'm sure you know this, but the page takes like 30s to load on mobile. It wasn't a comfortable ux. Once it did load it seemed pretty fast though so kudos. Kind of gave me macromedia flash vibes from 2002.
Yes, the initial download of pyodide is about 5 MB. After that it is another 5MB for the bundle wheel.
But there is some hope: Based on test I just did, I see I did not setup headers so that the wheel and pyodide are cached in a browser (or in its fs): this could reduce reload times by a sizable factor.
Once loaded you can run at 60 FPS (or even 120 FPS depending on the browser's vsync).
As you can see in the playground: you can then switch from app to app instantly once pyodide is loaded and running. It almost feels like going from a page to another. You can see that when using the combobox to select example at the top right in the playground.
For real world use I don't think its practical if its only goal is basic browser UX in Python versus JavaScript, but I can see amazing value in this for larger applications written in Python that need to make use of a Python GUI.
As an example, I once built an online stock/ticker app with it: smooth real-time updates in a nice plot. It would have been more complex with DOM based widgets (and probably less fun).
There is a minimal amount of JavaScript just to download and run pyodide and then it is only Python: see example at
https://imgui-bundle.pages.dev/playground/?demo=p_35_minimal...
What I do not like is the strange mix of technologies you have to cope with in order to work with Python on the web: your project is often a mix of python / html / css / react / js / node.
Many very nice frameworks try to abstract this and present you only the python side; but they rely on this stack internally. Once you want to reach complex use cases (such as a refresh at reasonable rate), you will have to "open the engine" and enter into this mix.