TL;DR
The core of your question seems to boil down to the following:
I used to have one project manager who handle all the client engagements but now [I'm] thinking of decentralizing this role and assigning future client engagements to different team members...[T]his team member would be the owner of this engagement.
When I parse this, it really seems to be two related questions:
- Is project ownership the same as project management?
- Can project management responsibilities be handled by technical team members?
The answer to the first question is "no." The answer to the second question is "maybe, but it's generally a bad idea."
Project Ownership vs. Project Management
Managing a client engagement is not quite the same thing as managing a project. While the roles may be related, they are distinct. In fact, some frameworks such as Scrum draw a distinction that places the Product Owner in the role of stakeholder management and championing the product, while the Scrum Master manages the project's process.
That doesn't mean the rest of the team never interacts or interfaces with the client. In fact, the principles behind the Agile Manifesto explicitly state that:
Business people and developers must work together daily throughout the project.
The division of roles is primarily intended to ensure that the project's process is managed cooperatively, while still controlling for scope creep and lost productivity related to interrupt-driven management. This division is often remarkably effective.
With that in mind, I'd take the position that asking members of your technical team to manage the business interface with the client is an inherent conflict of interest. While it can work, it's certainly not considered a best practice.
Who Should Have Project Management Responsibilities?
The second half of your core question implicitly assumes that project management is a hat anyone can wear. While it's certainly true that some technical leads are more than capable of managing a project, it can also be a recipe for failure for several reasons.
Firstly, a key aspect of project management involves applying controls to a project. This creates an inherent conflict of interest for anyone who is simultaneously responsible for both delivery and process control. This is the same separation of duties concern that leads responsible organizations to separate finance and IT from internal audit: asking the fox to guard the hen house is simply a poor strategic decision.
Secondly, project management is a separate profession for a reason. Turn the question around: could you expect your middle managers to write code as effectively as your hands-on developers, or your CEO to sort mail as efficiently as the mail room clerk who does it every day? No doubt there are developers with cross-functional skills who could make great project managers, but in general you will see a higher level of efficacy by ensuring the role is filled by someone who has sufficient skill and experience to handle project management responsibilities as routine.
With the foregoing in mind, I would recommend getting your developers as involved as possible in the project management process, but would leave the functional responsibility for project management with one or more dedicated project managers. Greater transparency and engagement within the organization could certainly lead to a more cohesive and cross-functional project team, but your mileage will almost certainly vary.