Record sharing features in salesforce (namely, role hierarchy, sharing rules & manual sharing), facilitate opening up more access, but not restricting access. So, assuming that your problem is related to creating contacts from account related lists (or specifying account lookup while creating new contact), your best bet would be to write an apex trigger on Contact object to accommodate various test scenarios. The trigger should check the level of access on associated account (i.e., the account lookup field value, if present) and throw an exception (which can they be shown as an meaningful error message in UI). Any other approach is likely to introduce loop holes. For example, if you attempt an UI customization (such as creating custom lightning component/ page or VF page to disable the 'New' button or the 'Account' lookup field), a seasoned developer could use API to create such contacts. You may opt to do a combination of these solutions if your requirements mandate on not compromising over user experience.
OWD defines the level of access the users have on the records that they do not own. By setting OWD as
private on Account and
Controlled by Parent on Contact, the users will be able to create both account & contact records, but they will only be able to manage (edit, delete, transfer) the records that they created.
Along with that we have given Read access to all internal users for
By doing the above, you open up read access to the contacts associated with the account. Since, OWD for Contact object is controlled by the OWD on Account object, now the internal users will have read access all contacts. If the internal users try to edit any contact record which they did not create, they are likely to end up with insufficient access error. However, this doesn't impose any restriction on creation of contacts and this is a valid business case where users might be allowed to create contacts but not accounts.
You could possibly implement the same in record-triggered flows (For this specific problem, I've not personally not tested using flows and so, no comments on the relevant pros and cons).