CPU clock speed versus CPU core count - higher GHz, or more cores for SQL Server?
The general rule of thumb is keep the core count as low as possible, and the processor speed as high as possible.  The licensing math on that proves the point at ~$7,500 USD per core for Expensive Edition.

Buying the correct hardware can pay for itself in reduced licensing costs. See Processor Selection for SQL Server by Glenn Berry. It's a great resource on how to choose a processor for SQL Server.

Once you take into consideration SQL Server's per-core licensing structure, it makes sense to always go with the fastest processor speed available, regardless of workload type, whether OLTP or analytics.  Having the fastest possible core speed is never going to be a problem.  Increase the core count as required, but never do that by reducing core speed.  

In other words, don't think of 16 x 2.2Ghz processors being the same as 8 x 4.5Ghz processors.  The cost savings of using the 2.2Ghz processors over the 4.5Ghz processors is likely to be a maximum of about $10,000 USD (for a typical Xeon-based two processor machine).  Jumping from 8 cores to 16 cores with SQL Server Enterprise Edition is likely to cost over $60,000 USD in licensing fees.  In other words, you might save $10,000 in hardware costs, but you'll lose an extra $50,000 in licensing.

If you decide you need a lot of parallel processing muscle, and decide you need 32 cores for the task at hand, going with the fastest cores will pay dividends in reduced processing time.  Nobody will fault you for that.

Having said all that, if the choice is one CPU or more than one CPU, always go with more than one.  Running SQL Server (or any DBMS) on a single CPU can cause all kinds of problems since the capability for concurrent operations is vastly limited.