To back up a step, this is a convenience feature--you get a fairly primitive through-the-web text editor in the WP admin screens for any files that you have set permissions appropriately (world-writeable in general). WP uses templates that are .php files in your filesystem, beneath the root of the WP install in a directory called wp-content/themes/<themename>.
I'll leave the discussion on the wisdom of directly editing your production template files for another thread.
The first threat here is that someone overwrites a template file. AdSense publishers have a bit more exposure compared to the rest of webmasters--their AdSense accounts can be yanked. There are also other subtle attacks that don't involve defacements (let your imagination run wild--picture arbitrary PHP code inserted into frequently running scripts on your site).
From a pure security perspective, world-writeable files are bad, and especially ones beneath the document root (since they can be viewed, or invoked if executable). But how bad is this threat really? At this point we sort of blur into a discussion about security of PHP and of shared hosts. But let's look at a few commonly encountered configurations in shared hosting environments, and the implications.
PHP can be configured to run in safe mode [us3.php.net]. This is a Good Thing, as it will make it a bit more difficult for other users that share your host to stomp around in your filesystem. The explanation in the manual is really great, so permit me to quote:
Safe mode can also be off (seems apalling, doesn't it?), in which case leaving any files world-writeable is a terrible idea. I'll refrain from explaining why in detail, but people sharing your host can write your files, via script. One workable strategy for mitigating this (aside from shopping for a more security-conscious host) is to do all development (template edits, trying new plugins, other hackery) on a throwaway instance of WP. This should use a different database, and ideally should be under a different document root. Then have a process for committing the changes to your production server. Make file permissions as restrictive as possible in production.
WP keeps your content in the database, even though the templates are in the filesystem. Generally this is good. But what are the permissions on your database? It turns out that if you have the appropriate password, it's effectively writable. What's the "appropriate password?" The one in yourwp-config.php. Yeah, that world-readable file under the document root. If someone on your shared host has this password, they have write access to your database, hence to your content.
Normally hosts will do a decent (not exhaustive) job of keeping others from browsing your portion of the filesystem. This really should include having safe mode on. If you can get a clue to the existance of a file on your host, you can write a PHP script that opens it (absent safe mode restrictions). This is why informative error messages are bad on your production server.
I feel like I've wandered a fair distance from the topic, but here's the quick summary:
+ Running WP (any script) in a shared hosting environment is not entirely secure
+ PHP's safe mode helps, but isn't perfect
+ filesystem permissions may expose your templates
+ WP has a feature that only works if you set your filesystem permissions to something dumb (forunately permissions aren't dumb by default)
+ database access retrictions may expose your content
+ WP has a world-readable config file
+ none of these threats open avenues for remote exploits (probably the key takeaway here--only your hosting neighbors can bite you)
+ do your template tweaking in a dev environment, especially if you're an adsense publisher
* The exception is if your host runs PHP under your user ID [suphp.org], which is quite uncommon.