Yes, that could be. In many situations starting teams will start with nothing so using Phase or Version to keep their state is handy enough. When applying filters, it becomes really visual. If this works for the team it is probably wise to change this approach. I like to use Sparx as much out-of-the-box as possible, so no fancy things, those are for later.
Yes, everything works till a certain level. After that you have to switch to a different approach. The larger the scale the more "formal" work is required to keep the repos aligned. So, a structure of repos containing specific parts of models is required for large teams. Tools like the Reusable asset service might be handy to have then. Also, it is important to remember that modelling information is required for only a number of teams and not all of them. So trying to put everything in one basket is not the way to go. Think about arranging in domains. And only exchange the top-level information of that domain. Abstraction is king! here.
Well there are things important as I tried to explain. First of all: Structure, Structure and Structure. Finding things in the repository should be self-guidance. Like: I expect to find elements about subject X there, so it should be there. As I said when you read a catalogue you know where to find something after you understand the structure. So, when required restructuring is necessary
So, if working with many architect’s time has to be said aside on how to make the structure work, now and in the future. So, keeping track of the quality of an element is becoming important. Promote elements that are verified.
About repository size. I have seen large repositories but hardly seen any performance issues (at least not for repositories that are in a DBMS in a "local" network. If have seen some performance issues on cloud-based repos (AWS and Azure), but less with those if put in the right data centre and with a more dedicated connection.