This is a standard "web security architecture" question.
A typical 3-tier app will have
- Web layer
- App layer
- Database (or other backend) layer.
The idea is to help segregate the duties.
So the "web layer" is the initial termination point for all incoming traffic. You might have your SSL stuff done here. At this point you can inject things like "Web Application Firewalls" which can inspect the incoming traffic for things that look like SQLinjection attacks, or path traversal attacks and so on.
The advantage of terminating here is that front end services like apache or nginx or lighttpd are dedicated to handling rogue traffic, to logging of bad requests, to being more "secure". Someone comes up with a new way of attacking web servers (data fragmentation with bad TCP bit set?) and you'll be sure that the top web servers will be patched; your web framework may not be so much on top of things.
Only traffic that is "clean" is passed onto the app layer (this communication may also be HTTP, but from a more trusted source). And your application can talk to the backend.
Now, ideally, these layers would also be on different servers with network routing rules so that the "application server" can not be reached at all from the external request service. The only way traffic can get to your app server is via the front end web server, even at a lower TCP layer. But even without this, you can gain some security advantages.
Secondary advantage means that your front end service could be a HA proxy, distributing load to multiple backend application servers.
So, from an enterprise viewpoint, there's a lot of good reasons to separate them. But it does require more work to configure and setup.
How far you want to go is a personal preference.