lets say you're going on a road trip. you have several options on how to get there. lets throw out public transport. you can either walk, ride a bicycle, or drive an automobile. If you ask a person who doesnt know how to drive or ride a bike, they'd rather walk because thats what they know how to do (been doing it their whole lives. they know a few tricks to make walking easier. they have good shoes, and they dont weigh a ton while traveling). if you ask somebody who's never driven a car before but knows how to ride a bike, I'm sure they'd rather ride the bike, because it gets them there w/ less effort. now ask the guy who knows how to drive a car, and they'd pick the car.
now they'd all get to their destination using all 3 different methods of transport. the car would get there first followed by the bike and the walker would get there last.
software engineering is the same way. you can write the app in machine code, but writing in assemble is quicker, but writing in a full featured programming language that can comple to machine code is even quicker than writing assembler. beyond this point you have the same type of thing. you can write all your code in a text editor or you can write it in an IDE. each one of these solutions will get you an application executable, but much like the foot, bike, and car situation, there will be one way that will get you to a running app faster and with less effort than the others.
I could be a genius at x86 assembler and write an app that is faster and more efficient (althoug it would only be capable of doing 1 thing) than the exact same app written in java. the java app however would take less time to write, and it would have more features, and it would be able to run on x86, x64, i64, sparc and mobile devices.
the reason for all this is that as hardware changes (monitor memory now is capable of storing more than 80 characters) the way we program them changes. as hardware gets more advanced, the code to program it gets more advance, and as that happens the way we write it changes.
vi was great on a little operating system at&t made a long time ago, when sh was the only shell around, and there was no windowing environments, and things were written in c.
when you're working w/ large frameworks, large code bases, and complex conceptual specs, a simple text editor will be like walking to the destination. it will be like using a very fast app that does 1 thing really good. unfortunately, the needs of the developer have moved far beyond being able to type letters into a buffer, or be able to run macro's in a text editor to search and replace any occurance of "foo."
if all you're doing is modifying a few lines of an existing application (or script as folks like to call php applications) on the remote server, ssh'ing into the box & using vi to edit the file on the drive, I'll agree that that is a better solution than ftping it to your local box, opening eclipse to change 2 lines of code, the ftping it back to the server only to repeat that process several times to fix what you're trying to do.
if your writing a forum system like punbb I dont think that using vi on the remote box is the best solution. having a local server / database, and using something like phpedit or zend studio (mmm debugger), or dreamweaver would be faster and more efficient than vi.
when I was in school all I used was vi or emacs. I wasnt writing huge amounts of code, nor things that required short timelines to develop large apps. it was a good tool for that.
seeing as how we're talking about little php scripts that probably arent object oriented, and dont do more than generate some little html files, I dont think it matters much if at all.