Are you editing? Yes == you will have to use a feature service (at least for editing).
Caution: Brain-Dump A-Head...
Feature services, have very limited symbology renders (compared to dynamic map /export services):
See 20027: Layer uses advanced renderer settings—Help | ArcGIS for Desktop
Feature services aren't necessarily great for highly complex geometries (i.e. lots of vertices) as the payload and requirements for many client devices to perform the rendering provides a poor user experience. Additionally, the max limit for feature services and a lack of client side (raw data) caching means there's likely to be a lot of I/O between client/server/database.
Feature services don't have a highly sophisticated control throttling the amount of data I/O. The service has a "max record" setting with a default of 1,000, however the geometry of 1,000 complex polygon features is far more complex than 1,000 2D point features. Similarly, not all polygon features have comparable complexity and may exist in the same feature class. It's not something we should expect Esri to address, but it is a characteristic of feature services you should be aware of an take it into consideration when evaluating their suitability. I've had 32,000 point's running perfectly find and seen 1,000 polygons grind Chrome to its knee's.
...cont. Something I have noticed in recent times is that the JS API appears to /query feature services for data in "tiled" chunks. So a single pan operation might spawn 6+ /query requests simultaneously to the server. I understand that this can provide a better user experience as data is obtained in chunks and the user will see a progressive loading of data. However, from a server perspective, this can hammer the server(s)/database(s) with multiple requests from a single client all at once. Each request exists within the max feature limit. So if you have the default limit of 1,000 the server is doing more work than you think. Additionally, the client may have to render a total > 6,000 complex features. I believe there's a way to control this behavior on the service but I have forgotten how sorry. I thought the simple request per map extent change was easier to configure/control/throttle but that's all in the past now.
Feature services/layers open up a lot of possibilities for client site development tools. This is because the data exists client-side whereas dynamic map services are just an image. They can be really useful and exploited for your own needs - so long as you are happy to develop.
Feature services can be great for printing secure data/services. The reason being that the client has the data and it passes it on to the printing server/services (to render). If you are using a secure dynamic map service, then the print service can't be supplied with data by the client. The print service needs security configuration so that it can talk to the secure dynamic map service. It can be complicated/problematic to get secure dynamic map services to print reliably. Esri should consider extending the output format of /export to support base64 so that the client can "fetch on forward" the images that the print service will require to compile its print output.
Dynamic Map Services are really good at rendering the output but it comes at a cost (nothings free). The load is placed on the server resources (not the clients) and I/O is highly likely (but not always) higher than feature services. So, you might need additional server infrastructure (note.... AGOL don't support these services and this is why).
Hope someone finds something in here to be useful.