ASM was introduced as an alternative to RAW devices, which in some systems provided a measurable performance advantage over a traditional filesystem. ASM provides the performance benefits of RAW devices with more flexible management. ASM also allows managing multiple drives without separate Logical Volume Manager software, giving the DBA more control over the storage layout (in shops that divide that responsibility between DBAs or System Admins).
ASM also adds redundancy for striping, balancing, and failure recovery - similar to RAID but designed for interaction with an Oracle Database. This provided another performance gain over some traditional RAID configurations, and more DBA control over how data is protected from hardware failure.
If you can achieve the same performance in a traditional file system, then use it. ASM is an option. If you claim "we can achieve the same performance" then I assume you have tools to measure that and can back up that statement with data. With performance metrics of both setups in hand you will see clearly which one has more advantages in your installation.
ASM offer several features which doesn't offer by any normal file system like :-
ASM manages the physical disk space as a logical container in the form of Diskgroup so that ASM let you allow to plug and unplug the disk at runtime. In addition when you plug and unplug the disks ASM automatically rebalance the existing data to balance I/O across the disks.
Moreover ASM balance the I/O across the disks to improve I/O performance.
From 11g onward ASM offer general cluster file system where you can put non-database files as well so no need of any other cluster file system.
ASM is better for two basic reasons.
Management and administration. It allows the DBA far better control, with features not found, when using a cooked file system. For example - you need to move the database from an old drive to a newly installed drive on the server. With ASM you can do this while the database is up, running and in-use.
Performance. ASM disks are block devices that are accessed using direct I/O. This bypasses a lot of moving parts that you will typically find in a cooked file system. Raw/direct disk I/O is faster than doing I/O via a kernel file system driver (that may or may not write that data to file on disk).
The con is that ASM is another s/w layer that needs to be installed, and which needs server resources to run. On the modern server, that is not a problem. It's not like running on a couple of sub Ghz CPUs with only 4Gb of system RAM. PCs today have more resources and faster resources than servers of a decade ago.
So there is not much reason for not using ASM.
I'm using ASM on all my database servers. From very small (dual core standalone) to large (12 node RAC). ASM has numerous times saved the proverbial day when there was storage issues, and required storage changes. I would need a lot of sound and hard convincing not to use ASM by default for an Oracle database in today's environment.