However, if I don't need protocols then can I start by not using protocols and when it's necessary to use them I convert my classes/object to conform to protocols.
Beware the old adage of painting yourself into a corner. This is a classic tale of how bad practice development often perpetuates itself because a dev team that didn't want to pre-empt good practice generally remains unwilling in the future to then spend even more effort (because now it's a bigger issue/job) to introduce that good practice.
It is much easier for code cleanliness to drop than it is to increase it.
However, that doesn't mean you need to do everything from the get go either. On the other side of the spectrum sits YAGNI, urging you to not develop things you don't yet need.
There is a careful balance to be struck here. And it's nigh impossible to strike that balance perfectly. So instead ask yourself which way you'd like to err. Would you rather save some effort today at the risk of increased (and more difficult) effort in the future? Or would you rather invest effort early in the expectation that it will pay back dividends in the future?
I can't make that decision for you, but as a consultant who has been brought in to several companies whose development culture had gone down the drain and were no longer capable of delivering projects; I can only offer the consideration that it's very alluring to put off the boring work of clean coding practices, and urge you to really consider if it's the best choice and not just the easiest choice.
My main concern is the development overhead of protocol (albeit small) is not beneficial until there is >1 user of the Interactor.
When an application is well liked and does its job well, people will inevitably try to do more and more with it. Eventually, the codebase will buckle under that increased usage.
Clean coding practices not only help with redistributing that added pressure, but makes it significantly easier to upgrade or scale up parts of your application.
Again, I can't tell you that you must invest in clean coding practices. Exceptions do exist. But the people who end up regretting their decision are by a large margin the ones who underinvested in clean coding practices, not the ones who overinvested.
To put it differently: would you rather have paid for health/fire insurance and risk never ended up putting in a claim; or would you rather not pay for health/fire insurance and risk the health/renovation bill when something does happen?
And 99% of the time in my apps there generally is only one Controller/Presenter connecting to my Interactor.
As far as logic is concerned, something either happens or it doesn't. There is no meaningful difference based on how often something happens. As long as there is a non-zero amount of use cases with more than one controller/presenter connecting to your interactor, you have to work out the logic for that non-zero amount of use cases.
And again, I can't tell you you must adhere to whatever practice you're being suggested. All I can offer is to really think through if it's going to work for you, and offer the reminder that humans often undervalue clean coding practice because it is boring and doesn't immediately reward you for it. The rewards are deferred until the future, when inevitably changes/upgrades/scaling/bugs happen.
But why would I spend the effort making everything private just because?
Think of it like the doors in a company. Should they be unlocked or locked by default? Well, that depends on certain factors.
If security and privacy is paramount (e.g. banking, prison, ...), then a company will opt to keep their doors shut and use e.g. badge systems for employees. But if the company wants to promote foot traffic, such as most shops, it's much better to have open doors.
In software development terms, you want to minimize the foot traffic to reduce complexity. Because of that, you take time to think about exactly who needs to be where, and you'd rather not give people access to places they don't need access to. Bob the accountant needs access to the office but doesn't need to be in the security office's armory, so to reduce the odds of abuse, whether willful or accidental, it's better to lock the armory door and not give Bob the ability to open that door. Even if he doesn't have ill intent, Bob is still a wildcard when left unsupervised with things that he is not trained for.
This is why the suggestion is to keep things private unless there is a public need for them. It ensures that outside actors can't just waltz in and start meddling with things that should not be meddled with. Much like how every person who wants to access the armory will be individually vetted, every time you make something public, you need to really consider whether this should be made public or not.
