All licenses which are compatible with the GPLv3 is also compatible with the LGPLv3 and AGPLv3.
All licenses which are compatible with the GPLv2 is also compatible with the LGPLv2.1.
"Compatible" here means that you can fulfill the conditions of both licenses, without it conflicting with the conditions of either.
In this case, the MIT license, BSD-2-clause and BSD-3-clause licenses are all compatible with GPLv3, LGPLv3, AGPLv3, GPLv2 and LGPLv2.1.
So, code licensed under the former can be copied into the latter or linked with the latter (statically or dynamically), and distributed together, as long as the conditions of all the included licenses are fulfilled.
The Combined Libraries clause of Section 5 of the LGPLv3 and Section 7 of the LGPLv2.1 is completely unnecessary and redundant for software licensed under compatible licenses. Rather, it is meant for software licensed under incompatible licenses like proprietary licenses and incompatible open source licenses.
For e.g. the Apache License v2.0 is compatible with GPLv3, LGPLv3 and AGPLv3 but it is incompatible with GPLv2 and LGPLv2.1. The reason for the incompatibility with GPLv2 is explained in this answer.
A library licensed under Apache License v2.0, like OpenSSL 3.x, is never usable by a software licensed under GPLv2-only due to this incompatibility.
However, a library licensed under Apache License v2.0, like OpenSSL 3.x, is usable by a software licensed under LGPLv2.1-only, as long as the conditions of the Combined Libraries clause of Section 7 of the LGPLv2.1 is fulfilled. This is explained in this answer.
OpenSC's libp11 is an example of this. It is licensed under LGPLv2.1, and it uses OpenSSL which is licensed under Apache License v2.0. Both libp11 and OpenSSL are open source software with publicly available source code. So, the conditions of Section 7(a) of the LGPLv2.1 is easily fulfilled.