I'm not sure how best to approach your question, other than saying "no, it's not a security issue". Abstraction has nothing to do with it. I'm not sure what your friend meant by it, but PHP does have abstraction (classes, inheritance, etc.) and doesn't require you to embed any HTML in your page at all. Modern PHP sites tend to have a data layer, a logic layer (usually facilitated by a set of classes that represent virtual objects on the site), and a presentation layer. CF likely has similar constructs.
One thing I will note (though I can't speak for CF) is that it's notoriously easy to write terrible PHP code, in part because it's so forgiving, and in part because most tutorials don't cover any basic security requirements.
However, here's a few reasons why PHP is considered "insecure" by some:
- Silent type juggling, leads to difficult to spot logic errors.
- Default configuration leaks information (displays errors,
exec enabled, etc)
- Tutorials for MySQL have a heavy dependance on
mysql_query with string concatenation, rather than parameterized queries with PDO or MySQLi.
However, no PHP code is transmitted to the client at any point. It is entirely server-side. It executes on the server, and outputs a result, which is usually HTML.
Don't get me wrong - I actually quite like PHP. It's easy to use, and (despite its quirks) can scale pretty well too. The problem is that it's too easy to write code. PHP makes it remarkably easy to introduce XSS, CSRF, LFI, RFI, SQLi, etc. into your code, because they don't document the potential risks alongside the API reference, nor do they provide obvious and standardised ways of approaching security issues.
My final point is this: languages aren't inherently insecure. Some may make it easy to write bad code but, in the end, it's the developer who created the insecurity, not the language.