Different modeling languages (Entity-Relation, Unified Modeling Language, and others) are simply notations for communicating a design to stakeholders. Communicating a design is technical communication, and one of the principles of good technical communication is to communicate the information clearly and concisely. Choosing a modeling notation that is understood by your audience and can communicate the desired information clearly is the first step to achieve this principle.
In his article A Comparison of Data Modeling Techniques, David Hay identifies a number of modeling notations and provides the same example model as expressed in each notation, including ER diagrams, Information Engineering, Barker's notation, IDEF1X, Object Role Modeling, and UML. Hay discusses the difference between analysts (who need clear and easy to read diagrams that can be reasoned about) and designers (who need complete, rigorous, and expressive diagrams to use for implementation).
Scott Ambler also has some principles of Agile Modeling are relevant to this:
Travel Light. Every artifact that you create, and then decide to keep, will need to be maintained over time. If you decide to keep
seven models, then whenever a change occurs (a new/updated
requirement, a new approach is taken by your team, a new technology is
adopted, ...) you will need to consider the impact of that change on
all seven models and then act accordingly. If you decide to keep only
three models then you clearly have less work to perform to support the
same change, making you more agile because you are traveling lighter.
Similarly, the more complex/detailed your models are, the more likely
it is that any given change will be harder to accomplish (the
individual model is "heavier" and is therefore more of a burden to
maintain). Every time you decide to keep a model you trade-off agility
for the convenience of having that information available to your team
in an abstract manner (hence potentially enhancing communication
within your team as well as with project stakeholders). Never
underestimate the seriousness of this trade-off. Someone trekking
across the desert will benefit from a map, a hat, good boots, and a
canteen of water they likely won't make it if they burden themselves
with hundreds of gallons of water, a pack full of every piece of
survival gear imaginable, and a collection of books about the desert.
Similarly, a development team that decides to develop and maintain a
detailed requirements document, a detailed collection of analysis
models, a detailed collection of architectural models, and a detailed
collection of design models will quickly discover they are spending
the majority of their time updating documents instead of writing
Multiple Models. You potentially need to use multiple models to develop software because each model describes a single aspect of your
software. “What models are potentially required to build modern-day
business applications?” Considering the complexity of modern day
software, you need to have a wide range of techniques in your
intellectual modeling toolkit to be effective (see Modeling Artifacts
for AM for a start at a list and Agile Models Distilled for
detailed descriptions). An important point is that you don't need to
develop all of these models for any given system, but that depending
on the exact nature of the software you are developing you will
require at least a subset of the models. Different systems, different
subsets. Just like every fixit job at home doesn't require you to use
every tool available to you in your toolbox, over time the variety of
jobs you perform will require you to use each tool at some point. Just
like you use some tools more than others, you will use some types of
models more than others. For more details regarding the wide range of
modeling artifacts available to you, far more than those of the UML as
I show in the essay Be Realistic About the UML.
Content Is More Important Than Representation. Any given model could have several ways to represent it. For example, a UI specification
could be created using Post-It notes on a large sheet of paper (an
essential or low-fidelity prototype), as a sketch on paper or a
whiteboard, as a "traditional" prototype built using a prototyping
tool or programming language, or as a formal document including both a
visual representation as well as a textual description of the UI. An
interesting implication is that a model does not need to be a
document. Even a complex set of diagrams created using a CASE tool may
not become part of a document, instead they are used as inputs into
other artifacts, very likely source code, but never formalized as
official documentation. The point is that you take advantage of the
benefits of modeling without incurring the costs of creating and
He also has some practices for Agile Modeling to help achieve these principles:
Apply The Right Artifact(s). Each artifact has its own specific applications. For example, a UML activity diagram is useful for
describing a business process, whereas the static structure of your
database is better represented by a physical data or persistence
model. Very often a diagram is a better choice than source code -- If
a picture is worth a thousand words then a model is often worth 1024
lines of code when applied in the right circumstances (a term borrowed
from Karl Wieger's Software Requirements) because you can often
explore design alternatives more effectively by drawing a couple
diagrams on whiteboards with your peers than you can by sitting down
and developing code samples. The implication is that you need to know
the strengths and weaknesses of each type of artifact so you know when
and when not to use them. Note that this can be very difficult because
you have Multiple Models available to you, in fact the Agile Models
Distilled page lists over 35 types of models and it is by no means
Iterate To Another Artifact. When you are working on a development
artifact -- such as a use case, CRC card, sequence diagram, or even
source code -- and find that you are stuck then you should consider
working on another artifact for the time being. Each artifact has its
strengths and weaknesses, each artifact is good for a certain type of
job. Whenever you find you are having difficulties working on one
artifact, perhaps you are working on a use case and find that you are
struggling to describe the business logic, then that's a sign that you
should iterate to another artifact. For example, if you are working on
an essential use case then you may want to consider changing focus to
start working on an essential UI prototype, a CRC model, a business
rule, a system use case, or a change case. By iterating to another
artifact you immediately become "unstuck" because you are making
progress working on that other artifact. Furthermore, by changing your
point of view you often discover that you address whatever it was that
causing you to be stuck in the first place. See the essay Iterate to
Another Artifact for more thoughts.
Single Source Information. Information should be stored in one place and one place only. In other words, not only should you apply the
right artifact you should also model a concept once and once only,
storing the information in the best place possible. When you are
modeling you should always be asking the questions "Do I need to
retain this information permanently?", "If so, where is the best place
to store this information?" and "Is this information already captured
elsewhere that I could simply reference?". Sometimes the best place to
store information is in an agile document, often it's in source code.
Read here for more details.
First need to identify who you are communicating with and what information they need. You should choose the appropriate modeling notation and models to communicate that information to them. Once the models are created, you should use them. They should be reviewed for consistency, they should be transformed into other models, they should be included in documents, or they should be used to guide an implementation.
If you need to, consider investing in training. If you're working with Systems Engineers who use SysML, maybe consider training everyone to read SysML models. If the software team finds the UML notation easier, consider training everyone in UML. It doesn't have to be a formal training class - it could be passing around links to useful websites, buying a few copies of a book for a company library, lunch and learn sessions, or external training (either off-site or a trainer brought in for a session). This may make it easier to reduce the need to have multiple modeling notations used.
Second, don't be afraid to throw away models. Perhaps the first iteration of a model could be an ER diagram. That could be used to understand the data and to create your database. However, in order to add more detail, you may choose to evolve that into a different model type, such as a class diagram. Depending on stakeholder needs, you may need to maintain both models. If you don't, though, throw the first model away so you don't need to maintain it or risk someone finding it and working off of an incorrect model. Future updates to the database could be driven through changes to the class diagram. At the end of the day, though, you don't want the same information captured in multiple places.
To very clearly answer your question: yes, there are reasons to use an ER diagram over a UML model. That reason is that the ER diagram is more useful to your stakeholders than a UML model. However, using an ER diagram once doesn't mean that you will keep it for the life of a project or product or that you won't be creating another model in parallel or from your ER model.
I'd also recommend checking out Scott Ambler's Agile Data site for more articles and information. It is connected to the Agile Modeling site and is part of the complete Disciplined Agile Delivery process, but it does have some good ideas regardless of the methodology you are following.