uv is so much more than just a souped-up pip. It can also, for example, do building and packaging.
It also has workspaces and subprojects features that are sneaking toward something like the full-fledged multi-artifact project support you get in Pants (or Poetry, with plugins). Except that their decision that the entire project must have one and only one global dependency solution means that there's no escape hatch if you ever end up in a dependency hell situation. Which is fairly common in Python for a variety of reasons. And, even when it does work, subprojects all sharing a single virtualenvironment means it's really easy to accidentally create an undeclared dependency and never notice at development time because it's already in the venv due to a sister project already having declared it. So if you have a project that builds multiple packages, you're on your own for implementing a solution to ensure packages with sane dependency specs get published to the archive.
That's a major reason why Python development culture decided to go with many project-specific virtualenvironments instead of a single global one like what uv is trying to drive toward. And it's true that it still allows you to do independent projects that reference each other at development time using path dependencies. But, unlike some of its more mature alternatives, it doesn't give you any help with replacing those path dependencies with named, version dependencies at build time. So if you have a project that builds multiple packages, you're on your own for implementing a solution to ensure packages with sane dependency specs get published to the archive.