What is the purpose of table partitioning I was advised by a senior DBA that you should never use Partitioning, instead use schema to group data. I am talking on large databases. I am not convinced with this, please advice

An offline application deployed in 350+ locations was converted into an Online Application Single Database (10 Million rows).

They created schema's for 350+ locations and created tables inside these respective schemas.

When I was asked to look into the issues, I wondered why this setup and was because they were advised by Senior DBA to go like this (My Concerns were, How to perform search operations across all schema, how to manage any changes in table 350+ is huge, if it is a single table with partitioning things will become easy)

When I consulted the senior DBA regarding this and why he didnt propose Table Partitioning Instead of different schema, "He said partitioning is logical" and will not work, if you split it into schema the performance will be better because database operations will be limited to that schema.

These statements confused me and thus seeking your views and experiences
When to use many schemas?

In PostgreSQL databases of multi-tenant setup, it is not unusual to see a separate schema for every tenant.  This serves mostly to separate data of the different tenants, as schemas give a very convenient way of setting security/access boundaries.  This means, if I used such a setup, customer A would not have access to Customer B's data.  If necessary, it is easy to set up overarching roles that can work across the different schemas (doing maintenance, producing reports, and so on).

In these scenarios, one might have data that is common across all tenants.  I would store these in a common(ly accessible) schema, to prevent unnecessary duplications, thus making maintenance a bit easier.

Addressing one of your concerns, doing cross-schema queries is easy when you know which schemas to go for.  If not, it might be tricky.  However, maintenance in such cases might need some (self-built) infrastructure (as a script to roll out table changes on all tables named your_table one by one) - but when it's already in place, the single tasks are not so complicated.

Do schemas help with performance?

On the other hand, having 350+ schemas for 10M rows is definitely not about performance.  With 10M (not too wide) rows on a decent machine one would not expect serious performance issues in the first place.  If they still appear, there are other means than partitioning that one should try first (meaning different indexing strategies, usually).  A meaningful partitioning scheme for such data is very hard to come up with: 350+ partitions are just that much a pain in the ass as 350+ schemas.  Not to mention that the per-partition data volume will be small (like 30k rows), and in certain cases planning the queries would take a hit - especially, when you try to have multiple tables partitioned the same way.