Balancing software quality and community contributions

I want my software to have a community, but their contributions are so bad

Consider your first contributions, many of your contributors are scientists with little background in software engineering
Do you give them all the tools? Provide guidelines
Let them grow over time
Offer more than coding (e.g. documentation, design)

In general you want as many contributions as reasonable. If it was useful for one, it might be useful for others.
Also consider that software is a tool, not an art! If it is functional and well designed, it does not need to be pretty (common pitfall for many maintainers who want their projects to be perfect)
There are legitimate reasons when not to merge (see Kindly closing pull requests): If it is irrelevant, incompatible, untestable, or unresponsible to merge, do not merge it.
Problem in Science: Useful for one publication, but do not want to have it in the main software. If your software is modular there is the alternative of plugins that ship with publications.

Time intensive, but: Less bugs, but also better community connections (Bosu et al.)
Apart from the technical benefits, they pose a social challenge: Different from journal peer review! More personal, more supportive, not anonymous.
Learn about new applications, areas users are interested in.
Becoming collaborators? Get a better impression of user’s abilities.