TL;DR

How does project management address the issue of managing people with differing abilities[?]

I don't think there's a single, canonical answer to this question. The approach depends on the project management framework, the skills and experience of the project leadership, and the company's culture.

As just one example, Scrum side-steps the problem of inefficient or counterproductive top-down or external assignment of tasks through the use of self-sufficient and self-organizing teams. The 2021 Scrum Guide states:

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

Other frameworks have other approaches, but the underlying problem you're describing is systemic and needs to be addressed as an organizational systems and process issue.

Some Useful Rules of Thumb

While there's no "one size fits all" answer to your question, the underlying problem of how to address skills and and tasking is inherent in the practice of effective project management. Each framework and practitioner is likely to have a slightly different approach. However, there are certainly some broad rules-of-thumb you can apply. These should generally include some or all of the following:

1. The project charter should clearly define the objectives of the project. People with knowledge of the problem domain should then be able to identify the key skills required to meet those objectives.
2. The budget for the project should be sufficient to ensure the project can be staffed with people with all the required skills, or contain budget for training people attached to the project on any missing skills. Pro tip: this isn't really an either/or thing; a good budget generally has buckets for both subject-matter experts and upskilling.
3. Team composition should generally contain all the skills needed to produce the project's deliverables. For example, most agile frameworks such as Scrum recommend that the team be cross-functional and self-sufficient to reduce (if not eliminate) reliance on external resources as much as possible. This in turn reduces drag and friction on the project, and enables better resource and process management within the project.
4. Agile frameworks generally rely on pull-queues, T-shaped people, and just-in-time planning. Collectively, these argue against the use (or even the value) of top-down task assignments. When done properly, projects formed around these principles avoid most of the problems you describe in your original question where you state that "We each got assigned the task we were worst at[.]"
5. Two key responsibilities for the project manager (or whoever is responsible for the framework implementation of the project) are communications facilitation and progress tracking. If the project is out of tolerances because of poor processes, insufficient tools or skills, or for any other reason, it is the role of project leadership to communicate the process issues to the team and to senior leadership. Unless problems are hauled into the light of day for inspection and adaptation, nothing will change.
6. Always remember that senior leadership is ultimately responsible for budget, staffing decisions, and company culture, and that they inherently own the outcome of any project. As a result, if they can't or won't help the team improve a defective process then they are most likely a key cause of the defective process. Q.E.D.

In my own professional experience, there are very few process problems that can't be solved by better communication and outcome-based progress tracking. Likewise, there are are almost no problems that can be solved by micromanagement, a refusal to address systemic organizational problems (e.g. poor hiring or team-formation practices), or a focus on individual utilization rather than outcome-based metrics. Push the former, avoid the latter, and you can generally improve almost any project.

Just remember that there's no silver bullet. Regardless of your framework or process, success is never guaranteed.