This is actually a great question!
OpenVZ is an operating-system-level virtualisation technology, where each node shares the resources of the main host. In OpenVZ, administrator can just change a setting, and a different set of resources would be provided to the user as a matter of course. That's why almost all hosters (including yours as you mention in your comments) implement upgrades and downgrades for OpenVZ, because changing the process and memory allocations is alike doing a change with the getrlimit, setrlimit(2) system calls, and changing the disc size is alike doing quotactl(2) system call. If you're not familiar with these system calls to understand the allegory, it's enough to look at the HISTORY section to see that they've existed long before Linux was created -- that's how primal, basic and risk-free they are. (OpenVZ has their own way of doing these things, but it's basically the exact same concept.)
Xen, on the other hand, is a full virtualisation of a typical hardware. Changing memory in Xen is alike physically adding or removing the memory modules -- would you ever do that to a running system, and expect for the software to be able to handle it? Same for processors. Same for HDD. So, big deal, just shut it down first, right? Well, yes, that's possible and totally fine in regards to the memory and the CPU, but the HDD is different, as it holds the data you'd like to preserve.
How is HDD different? In OpenVZ, the HDD you see is just a subset of the actual files from an existing host filesystem, basically; if you have no files, it takes no size; and all limits are effectively soft. In Xen, it'd be the actual filesystem, backed by a file of a certain size on the host, same size as your virtualised disc.
Let's forget virtualisation for a minute. Now, if you ever did a verbatim copy (with dd(1)) of a smaller HDD to a larger HDD, you'd know that the results would appear identical, without showing any disc space increase. That's because you're copying the actual filesystem and the disklabel(5) of the disc verbatim. If you then wanted to use more space in the same filesystem, you'd have to first edit the disc's MBR partition with fdisk(8), then disklabel with disklabel(8), and only then call growfs(8) to actually increase the size of the filesystem. The filesystem itself contains various metadata throughout the whole disc, so, it has to be grown and shrank with a special command. If you look at the manual page, you'll notice that growfs itself is a much more modern invention (might even be a catchup to GNU/Linux!), and, at least in the BSD world, it's still missing a requisite "shrinkfs".
Now, back to Xen. The HDD of your VPS is likely backed by a single file of a specific size on the underlying Xen host. In order to shrink it, you'd first have to shrink the underlying filesystem within your VPS (luckily, unlike ffs/ufs in *BSD, shrinking actually is supported in Linux for ext2/ext3 etc), then worry about the disklabel/fdisk, as applicable. Only then could the Xen hosting provider truncate the underlying file that backs your HDD.
Suffice it to say, it's all quite possible, and Linode, for example, does automate all of these things (including automatically shrinking and growing your filesystem as needed, without any intervention from your side). But, needless to say, all of this does sound much more complicated than just making a system call (which doesn't really have to do anything other than modify a variable and restart a process), doesn't it?
P.S. Quite often, hosters specifically refuse to downgrade the pricing on older orders, telling the customer to re-order instead, because they know that not everyone will bother to go into such hassle just to save a few roubles here and there. And for the hoster, that's extra revenue.
However, in terms of keeping your IP address, you might enquire with your hoster if it'd be possible to re-assign your old IPv4 address to your new server once you finish the migration. If they're not willing to offer anything like that, either, then I'd suggest you strongly consider migrating to their competitor.
