Scrum doesn't blindly suggest "small teams" without qualification and definitely doesn't advocate for having a team so small that one member being sick means that work can't progress. The Scrum guide says (emphasis mine):
Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to be useful.
In the scenario in your question of only having 3 development team members, you would be right at the lowest sized team that Scrum recommends. There are various ways to reduce the risks you describe from one team member being unavailable, the most obvious ones would be
- Cross-skill team members
- Increase the team size
Doesn't it negatively affect the project success? Not in any way that wouldn't also apply if you weren't doing Scrum and were bottlenecked on individuals.
If, for example, a backend developer gets sick, then what should we do as a manager? Short term, discuss with the team what the most valuable thing is they can do without that member being present. Long term, work with the team to remove this bottleneck.
Should a customer pay for our work as earlier, despite the fact that we can't produce as much value as when the whole team worked together? - If you can't produce as much value using Scrum as you can when using a different methodology, then either adopt that other methodology or improve how you're doing Scrum.
How this situation should be stated in a contract document? - I wouldn't expect a contract document to get into the level of detail of discussing what happens when a team member is sick.