Stories: estimate effort alone, or client feedback component?

I don't understand why the customer would impact the team's ability to take a need and design and implement a solution.

Someone, often the Product Owner, takes stakeholder needs and turns them into Product Backlog Items. The Product Owner is accountable for communicating these Product Backlog Items and, through them, the underlying stakeholder needs to the rest of the Scrum Team. I can see cases where getting the necessary information from some stakeholder groups could be challenging for the Product Owner. However, once the Product Owner believes they understand what the product changes need to happen, they can bring these to the team, where they can go through refinement activities. At refinement, the whole team can get clarity on the underlying meanings and intentions, add details to the work, and break the items into smaller pieces that can be designed, implemented, integrated, and delivered.

Until the work is integrated and delivered, the Product Owner represents all stakeholder groups. I'd find it unusual for a stakeholder, especially a customer, to interact with the team throughout the development process. I don't mean to say that the stakeholders shouldn't be involved. For example, waiting for the Sprint Review to get feedback on the work would add a potentially unnecessary delay. The work should meet the Definition of Done when it is shared with stakeholders for feedback. Any input that needs to result in product changes would be captured as Product Backlog Items and go through a workflow similar to what I previously described.

But how do we account for interacting with the customer? Some clients are high touch, some very easy-going.

We might score this story a 2, but knowing who the customer is might warrant an 8.

That's telling you the work isn"t ready for Sprint Planning. Until these uncertainties are addressed, the Developers can't estimate how much time, effort, and complexity is likely to be involved. It may even be too big to fit in a Sprint.

Product Backlog refinement is the art and science of making work ready for Sprint Planning, so it can be chosen to help meet a Sprint Goal, and the associated risks controlled. Have your enabling conversations with the customers before any commitments are made.

But how do we account for interacting with the customer? Some clients are high touch, some very easy-going.

We might score this story a 2, but knowing who the customer is might warrant an 8.

Not sure why customer would impact the estimation. From what you are mentioning it seems you are trying to include the requirement gathering (customer discussions) as a part of the effort. That should not be the right way. You should include only clear ones in your sprint planning and estimate the story.

Requirement clarification would be a part of backlog refinement and not essentially a sprint activity in my view.

I echo everything that has already been said and want to emphasize the comments by @Ian.  If you feel the need to increase the complexity of an estimate because of the fear that the stakeholders may want changes, then this is not ready for a Sprint.  In fact, if that is going to be your process for every Product Backlog Item, then you may never get anything ready for a Sprint. 

Empiricism is an essential part of the Scrum framework.  Empiricism is a philosophical belief that there is no inherent knowledge and all knowledge comes from learning.  In order to learn, you have to do something.  Then you inspect the results and adapt if necessary. The reason that the framework uses iterations (i.e. Sprints) is so that something can be done and learning can occur. I always teach that you make a decision based upon the information you have right now, do something, inspect the results and adapt if necessary. Everything is an experiment. The experiment might now yield the results you expected but it is not a failure.  It becomes a failure if you choose not to learn from it.  

The Scrum Guide never mentions anything about user stories.  It says nothing about story points.  The word estimate does not occur in the guide. I have had a lot of success with teams that are just starting out by not using user stories.  The teams seem to do better if you just state the needs in terms that would be used in everyday conversations.  The Product Backlog Item should communicate the needs of the stakeholders and explain the change that is needed to the Product. If you have to fit all of that into a specific format, it can add some frustration.