The only advantage of having the mobile app communicated directly with the database is that it might be faster to implement in the short run.
In the slightly longer run, three layers are a much better choice for several reasons:
Flexibility - have the mobile app work against a service layer (for example, through some JSON APIs) that abstracts the database internals. This will make it much easier to make changes to your schema, even replace the entire data layer, without breaking the mobile clients. This is critical when you release new versions that involve changes to both your mobile app and your data layer, and have some apps out in the field that didn't update yet. A service layer will make support for multiple versions manageable. Working directly with the database would make it very nearly impossible.
Security - managing user logins, permissions etc. is usually not as well supported in the DB as it is in a service layer.
Scalability - should your app succeed and you'll need to scale the server side, a service layer would greatly increase your options (going back to no. 1 - flexibility).
This should be enough to get you convinced, but I'm sure other replies will come up with more :)
Regarding your other questions - recommend a technology/architecture for the server, there are lots of viable options - Ruby, Python, PHP, Node. The "best" depends on what you're already familiar with.