SQL Server - Data and Log Separation
The log vs. data separation is sound advice, but the devil is always in the details. A write intensive workload that commits frequently requires the log stream to flush to disk as fast as possible. This in turn requires a sequential write pattern, as the log does, undisturbed by any other operation. Hence, isolate the data writes (and reads!) from the log writes.

But the question is: is your workload write sensitive? Is the log commit flush wait the most important performance bottleneck? You may have a tempdb sensitive workload. Or you may have a workload that is not even touching the disk. Lock contention, memory restrictions, latch contention all could be your nemesis, none would be solved by how you separate LDF and MDF. And lets not forget that the modern SQL Server instance usually hosts several databases, implying several separate log streams.

In lack of further evidence, both you and your admin are equally right/wrong. You need to measure, identify your problems, and address them accordingly. Read How to analyse SQL Server performance for general directions how to identify (and address) your bottleneck(s). 

Before I go, I recommend you read:


Benchmarking: Introducing SSDs (Part 1: not overloaded log file array)
Benchmarking: Introducing SSDs (Part 2: sequential inserts)
Benchmarking: Introducing SSDs (Part 3: random inserts with wait stats details)


Not saying that, w/o proper consideration of the workload and value, you should use SSDs (yes, you should, always...), but just food for thought.