Are there any significant differences between raid volume and partitions?

The answer to this is entirely situation-dependent.
You need to assess your particular environment and your particular needs to make a decision on RAID volume layout and partitioning schemes.

The difference between the two ways of handling this comes down to "one RAID volume or several".

With one RAID volume you have simplicity - you are partitioning one big block of space.
That simplicity comes at the cost of performance: all of your requests are hitting one RAID volume, so as you scale up and add more requests you get closer to saturating the available bandwidth in that volume.
There's no distinction between requests, so if your machine is swapping heavily and trying to read data out of a database at the same time those two tasks will be trying to hit the same pool of disk bandwidth, and can cause resource contention which ultimately reduces performance.

Multiple RAID volumes allow you to split up "types of requests" across different disk groups, and possibly different RAID controllers, to maximize available bandwidth.
Using our "Swap versus Database" fight from above, if the swap space and the database are on different RAID volumes they won't interfere with each other: The swap requests are hitting the swap volume's disks, and the DB requests are hitting the DB volume's disks. This eliminates the resource contention, and allows for better performance.
The performance comes at a cost too -- you lose the simplicity of a "one big block of space" design, and have to think more carefully about assigning disks to RAID volumes to ensure you don't run out of space. You may also need to buy more disks in order to properly structure this sort of environment.

Three potentially illustrative examples:

Basic "Front-End" Server

For a simple "front-end" server, something that just runs a web site and makes all of its requests to back-end systems/databases, a single RAID partitioned by the OS usually makes sense.

You aren't going to be storing data on this box, and the read/write performance is usually not critical since the disk I/O volume is low and your application code will usually fit in RAM/cache - all you want is for the system to keep working if you lose a disk.

File Server ("File Dump")

A file server (or "File Dump") can often be broken up into two RAID volumes:

• The OS stuff
• The File Storage

In this case the "OS Stuff" will be subdivided the same way as above, but the "File Storage" RAID volume may be one big partition, or multiple partitions.
One reason for doing this could be to provide different RAID levels (RAID 1 for the OS stuff, RAID 0 for the data (if you don't care about redundancy and just need space), possibly across different classes of drive (fast file storage, slower/cheaper OS disks).

Database Server

Database servers are the complete opposite end of the spectrum from the "Front-End" server.
Typically you break them up with multiple RAID volumes for:

• The static OS files, and possibly OS log files
• Swap space, though you hope to never use it
• Database table space
  • Possibly multiple tablespaces, if we're talking about high volume
• Database transaction log space
• Database backups (dumps)

The first of these may be further subdivided by the OS, but the remainder are usually partitions, on top of discrete, dedicated RAID arrays.

Here the RAID volume layout (and partitioning) are really dictated by database performance factors, and you'll typically follow the recommendations of your database vendor (or DBAs), which will focus on multiple spindles (sometimes on multiple controllers) to maximize disk throughput.