TL;DR
The goal of Scrum is really to build trust through reliable and sustainable delivery of potentially-shippable increments of value. If your process is already doing that, don't break it. If it's not doing that, then some continuous improvement and inspect-and-adapt is certainly in order.
Utilization: Less Important Than Trust and Reliable/Sustainable Cadence
In Scrum, the goal isn't 100% utilization but sustainable pacing and reasonable accuracy, part of which is ensuring the team doesn't mis-estimate its work or routinely commit to work that it can't complete within a single iteration. So, regularly completing 100% of committed scope is great.
What you're really asking is something else. The hidden question seems to be: "If my team is always delivering 100% of agreed-upon scope, does that mean they aren't busy enough?" In other words, you're asking whether they have excess slack in the process, and if they should be committing to more work each iteration.
Maybe.
This is good fodder for a retrospective. If the team is completing all committed work halfway through the iteration, then they probably are mis-estimating or not accepting enough story points into the Sprint. However, if they are routinely completing all work that they commit to, have enough slack to ensure that they can handle variances and roadblocks, and aren't "sprinting" so hard that they burn out, then pouring on more work isn't necessarily constructive.
How to Inspect-and-Adapt Your Current Scrum Implementation
Instead of asking whether your team is under-utilized, a better set of questions might include:
- Is the team's delivery cadence adequate for the business' needs?
- What's driving the business' desire for a faster delivery cadence? (Hint: perhaps there's a trust issue or hidden process issue that needs to be addressed.)
- If the business wants a faster delivery cadence, are they willing to accept the risk that some Sprints may deliver less than 100% of accepted work?
- Is the team able to sustain an increased cadence without sacrificing quality, scope, or the Definition of Done?
Remember to start with an analysis of the major premise. In this case, that means asking why meeting 100% of commitments isn't seen as a good thing. There may be legitimate reasons why this isn't good enough, but make sure you (and the team) understand what those reasons are so that the team as a whole can address the underlying organizational and process issues.
Conclusion
If the team is meeting the business' current needs, and the team is happy and productive, then I wouldn't recommend messing with success. On the other hand, if the process isn't meeting organizational objectives, or if there are trust issues between the team and the larger organization, then that's definitely a discussion that needs to be had.