Surrogate Keys in Database Schema Design – Mr. Joel Kemp

On the first day of Database Systems, I asked the instructor about the introduction of "Artificial Keys" in a table’s schema (more formally known as Surrogate Keys). I had used surrogate keys in almost all of my DB schemas prior to this class. He urged us to avoid surrogate keys (and use natural keys from existing columns in the table) saying that surrogates are a method for achieving a form closer to 5th normal form and the performance upsides (if any, according to him) were negligible as indexing on a multiple-columns was as easy as indexing on a single column. 

Frameworks like Rails and CakePHP often reward the use of surrogate keys by making joins "auto-magically," assuming that you used a surrogate key structure to define foreign key relationships across tables. Yes, you can override the behavior of these frameworks to use natural keys; however, intuitively, if you’re abiding by all of these conventions imposed by the technology, then you might naturally gravitate to using the preferred, surrogate keys. 

From my experience, surrogate keys make systems far more extensible and adaptable to change with minimal alteration of dependent tables.

Is this another example of academia not reflecting the truth of real-world systems?