uboot is more striped down than traditional INT call based BIOS because it doesn't provide a boot API, or any "runtime" services. Basically it does little more than early hardware init, and jump to kernel image. For example it doesn't have an execution environment for option roms. Its great if your shipping a device with a fixed hardware configuration and kernel, but what ends up happening is that it fails to provide "platform" abstractions to the kernel. The result is constant churn at the platform level because even simple operations like "I want to boot this kernel/configuration on the next boot" cannot be communicated from the OS/kernel to the firmware in a standard way.

UEFI OTOH, is a bad combination of BIOS and openfirmware, but has standardized an execution environment that allows device vendors to build standalone "driver" packages that enable booting off plug-in network boards/RAID controllers/graphical display/etc.. Those drivers can then either be installed in the firmware or provided on option roms. There is a higher level API so that grub/whatever can say read a config file written by the OS without having to know the underlying technology.

Basically uboot is great for devices that could do without firmware and just boot a kernel, uefi is useful if you want to have a standard environment usable by a generic kernel/OS across a wide range of devices because combined with ACPI AML/etc it abstracts away much of the underlying platform management.

It's different because uboot typically resides on what I would refer to as "end-user" storage. If it booted from an on-chip or on-board flash/ROM device and then loaded content from the end-user's device, you're right -- in that case it would be remarkably similar to BIOS/UEFI.