My interpretation of Jeff's answer is "you're asking Lightroom to do something that it was never designed to do, and almost certainly never will do".
If Adobe started to offer pixel editing in Lightroom, the feature creep would be dreadful. People would be asking "why can't we have this from Photoshop", "my favourite Photoshop feature is missing" and "can you add support for Photoshop plug-ins". Before long, the to-do list is to reimplement Photoshop in Lightroom. Why bother? Lightroom already works well alongside Photoshop, much as there's scope to improve things.
It's not really a programming language thing - though the way Lightroom is written doesn't lend itself easily to pixel editing code. The biggest problem is a design paradigm one - offering pixel editing in Lightroom would break Lightroom's paradigm very badly. Breaking an application's design paradigm, or at least changing it dramatically, is one reason why applications become confused and confusing. The changing uses of Photoshop over the years, and the amount of bolted on functionality is much of the reason behind its confusing nature for those new to it, and there often being several different ways to do the same thing.
Just one example - how are you going to store those pixel edits? They can't go in the database - no SQL implementation is that great at handling huge blobs of binary data, and the database would become huge. If you're putting them in separate files, why not use .psd for compatibility purposes - at which point, why not use Photoshop anyway?
Lightroom's design paradigm is very elegant - it's a metadata based photo manipulation package, based around a relatively lightweight database. The history implementation in Lightroom works because each change is a relatively small chunk of metadata - that is not the case when pixel editing. Lightroom has no concept of layers, and almost every time I'm working on a photo in Photoshop, I'm using layers - whether it's different versions of the same image blended together, bracketed shots, different versions of the same image (you can do some fantastic things with group shots in Photoshop CS3!) or putting several images together to make a panorama.
To get the most out of Lightroom, you have to embrace it as it's designed - not try to force it into your existing workflow. I wrote this post over at photo-i
in reply to someone who was really trying to use Lightroom as Bridge on steroids, and was finding it deeply frustrating. It talks about the strengths and weaknesses of Lightroom 1.0 as I see them, why I find Lightroom such a rich environment in which to work, and it mentions Jeff Schewe's comment to me in these forums that Lightroom is an 80/20 application.
Lightroom is written the way it is for a reason. It does not have all the bells and whistles of heavyweight DAM, the pixel editing capabilities of Photoshop, the high end features of some of the Photoshop plugins we use, and the full power of the likes of Flash, Dreamweaver and Qimage on the output side of things. There again, with that power of those applications often comes a steep learning curve and confusion as to what's the best way to achieve things.
Lightroom is largely free of a steep learning curve and confusion over how to do things at the moment; long may it stay pure to its design goals! There's neat time-saving tricks to learn with Lightroom, but it's the sort of application where it doesn't take that long to become very productive. Can anyone really say the same about Photoshop, or other heavyweight and powerful creative applications like InDesign and especially Flash (you're never going to start to write complex ActionScript overnight, especially if you don't have a programming background)? You don't tend to see posts about "how do I achieve this effect in Lightroom" - the sort of post that often fills Photoshop forums. If you can do it in Lightroom, someone can give you a preset for it, and examining that preset tells you all about how it was done.
Lightroom is a highly productive environment for sorting, culling, rating, captioning, keywording, developing and cropping images, with more power than we ever had with ACR 3 for toning, spotting, monochrome conversions and - once we get the ACR 4.1 feature set in Lightroom 1.1 - capture sharpening and a local contrast enhancement like technique (which I love - Clarity is an excellent feature). In other words, Lightroom offers a rapid way to do all that most of us do to most of our images without needing any other software.
Lightroom also offers us a lightweight DAM setup which is sufficient for many tasks, such as "show me all the images with this keyword" or "show me all the images at this location", as well as the Collections functionality. You can't do that with Bridge, at least not without a whole bunch of disk searching.
Lightroom interfaces well to Photoshop. If you need the power of Photoshop, all your Lightroom edits can be made available either via Lightroom's Edit in Photoshop (which I confess I don't like, because you can't choose the folder and filename used, also you can't open a file as a Camera Raw Smart Object in Photoshop CS3), or via XMP and Photoshop.
Eventually we will get a Lightroom SDK - though Tom Hogarty has said it won't be in 1.1. Lightroom can't use Photoshop plug-ins for fairly deep architectural reasons - a Lightroom plug-in would have to be more akin to a Photoshop CS3 Smart Filter than a traditional filter, also much of Lightroom is written in Lua whilst Photoshop uses, I believe, a mixture of C and C++. Tom has said that Lightroom plug-ins will interface in Lua, and I believe part of the delay is to get the internals of Lightroom right before designing the interface to external modules. Once the interface is designed and the SDK issued, it will be very hard to change. Getting this sort of software design right can be a very long and exacting process - I've done it professionally. What seems logical to a software engineer with an engineering mind often turns out to be nonsense for the users. Get the SDK wrong, and it's very hard to change in the future. I lost track of how many times I had to redesign a user interface I was working on, and that was before it would pass critical peer review with my colleagues.
When we get a Lightroom SDK, it should allow developers to create parametric versions of the plug-ins that I commonly use in my workflow. I could certainly have a version of PTLens, and I would be grateful for some of the features of Photoshop CS3's Lens Distortion (particularly the perspective correction - I'm not fortunate enough to have a tilt/shift lens).
Noise Ninja would be great, though I would expect it to lack the noise brush (which I never use anyway; I use masks - Picturecode, if you're listening, I'd love a Smart Filter version of Noise Ninja, as I've already mentioned in your forums). If Lightroom could somehow expose the edge masking functionality that is under the hood in the sharpening features of ACR 4.1, that would probably be all the masking I'd need for Noise Ninja (I tend to over-correct noise on a second layer, then apply a edge mask to protect my edge detail). That illustrates how important it is to take the time to get the SDK design right - exposing the right Lightroom functionality to plug-ins will make for a better experience for developers and ultimately users.
If I had PTLens, Lens Distortion, and Noise Ninja (without any masking features other than some way to mask edges), that would cover the majority of images I take into Photoshop. If Adobe could either get Lightroom plug-ins working in ACR (which might be difficult, as the UI code is different in ACR and Lightroom; I don't think ACR's UI is written in Lua) or round tripping into Photoshop as Smart Filters that are set up to correspond to your Lightroom plug-ins, that would be an excellent state of affairs.
I appreciate that some people have specialist sharpening workflows, using the likes of Photokit Sharpener. I believe part of this is addressed with the new capture sharpening in ACR 4.1, which will be in Lightroom 1.1. Output sharpening in Lightroom may need beefing up as well - but creative sharpening, because it isn't a global transformation, probably is going to need Photoshop or similar. I'm not holding my breath for the Lightroom SDK helping those who want creative sharpening capabilities in Lightroom.
As soon as you start to have too sophisticated a requirement - especially for transformations that aren't global - you're going to need something like Photoshop. I suggest using Photoshop - whilst it undoubtedly has some cruft that has built up over more than ten versions (though Photoshop CS3 is 10.0, there was at least one x.5 release), it's an environment that many of us know how to harness, and there have been significant improvements from version to version.
If there's going to be any significant redesigning and improving, I think it's far more likely to happen in Photoshop. CS3 shows that photographers are being listened to - for example, the revised Shadow / Highlights algorithm in CS3 that curbs the tool's tendency to clip.
I avoid pixel editing whenever I can - my workflow is very parametric and non-destructive in nature, though some of my parametric adjustments are masked (such as colour fill adjustment layers in Photoshop coupled with a layer mask to correct colour temperature differences in part of the image). I look forward to a future where more of the parametric stuff can be done without leaving Lightroom, but there'll always be a place for Photoshop.
In the end, Lightroom and Photoshop are complementary tools for me. If I want to scan an image, retouch some defects, sharpen it, set a clipping path and take it into InDesign, Photoshop is the right tool to use. If I want to manage a bunch of mixed assets, Bridge is the tool to use. When I want to go through a day's shoot with my digital SLR, Lightroom is the quickest way for sorting, culling, rating, captioning, keywording, developing and cropping images. It has an important place in my workflow for those reasons.