The basic architectural themes have remained the same. You upload a small kernel of code with your business logic, and App Engine deploys enough instances to satisfy the demand. If you want to store data or synchronize your work between sessions, you have to use Google's proprietary data stores and caching, but everything else feels fairly standard. The first versions of App Engine used Python, but now you can push up Java WAR files filled with JSPs, servlets, and server-side logic. The administration is handled through a separate Web interface. Command-line issues are pretty much relegated to the past.
I think the biggest challenges for programmers will be adjusting to Google's nonrelational data stores. When App Engine first appeared, there weren't so many NoSQL projects around, and the idea of storing collections of name-value pairs was more of a novelty. Anyone approaching App Engine with a bit of experience with NoSQL won't be shocked at all by the simple solution that App Engine forces upon everyone who wants to keep data around. But anyone who still thinks of JOINs and normalized data will need to break from the table-oriented, relational past and adjust to a new way of doing things.
App Engine offers two classes of the data store, so the architect must decide whether to pay for additional power. The basic model makes one data center the master and all others a slave. If the data center fails or starts up a scheduled maintenance, your data can't be stored. You must be ready to live with a "planned read-only period." Many modern Web applications (think Facebook) can easily survive these kind of glitches, but applications requiring banklike levels of availability and consistency will need to look elsewhere.