Database files, transaction log files and temporary data files are usually placed on different volumes to reduce I/O contention between them, and this can also be extended further by creating multiple data files for each database, spreading them across even more volumes and telling SQL Server where specific tables and indexes should be stored; so, yes, this is a common practice for DBAs, and can indeed lead to significant performance gains.
It is also true than it can become completely meaningless when using a SAN; depending on how that SAN was actually configured, different LUNs (volumes) can be mapped to any set of phsyical disks, RAID arrays and storage controllers, and thus the I/O contention between two LUNs can range anywhere from "completely isolated" to "effectively sharing the same disks". So, unless the DBA is working closely together with the storage admin, asking for different LUNs in order to spread database files between them can indeed become a completely wasted effort.
However, separating database files and transaction log files is considered a best practice not only for performance, but also for reliability: due to the transactional storage engine being used by SQL Server (and to similar engines used by almost any existing DBMS), log files can be used to replay transactions in a disaster recovery scenario, enabling the system to recover what happened after the last backup was taken. But, in order for this to work, you don't want to lose data files and log files at the same time, so it's better to at least place them on different volumes, even if there is no performance gain from this.