Splitting a table based on enum value
If you never or rarely need to access more than one type at a time, then consider splitting.  However, personally I wouldn't do so.  I've been involved in a number of projects where this has been done, and result in a lot of additional complexity with little benefit.

The companies table appears to be a good choice for the common data.  Migrating data when a company changes type will increase complexity.  To enable this to work well you will need a table to generate ids from, and rules to ensure the same id doesn't appear in more than one sub-table.

I would consider splitting type specific columns into separate tables.  This will require different queries by type.  Again this may make the application more complex.  As there are only a few smallish columns, keeping them in the main table likely has relatively little overhead and simplify the overall design.  If you have many or larger fields which are type specific and only of use when the type is known, then consider splitting the sub-type data into another table.  It can share the same key as the relationship will be an optional identity relationship.  

Another case where I would consider splitting a record is where there is a mix of tombstone data and highly transactional data.  I've seen it work well with parts, and inventory data.

Having worked in a company where suppliers were also clients, revisiting how suppliers and clients are differentiated might be a worthwhile exercise.  I would consider splitting suppliers into a separate table based on the following criteria.


Systems dealing with suppliers are separate from those dealing with customers. 
There is little prospect of reusing access routines between the systems. 
Volumetric data indicates that a least one system could get substantially better performance from splitting the tables.
Security/access requirements for the two type of companies are significantly different. 


Reviewing what happens to prospect data when a prospect becomes a client may be a worthwhile exercise.  If it is retained, it may have value in determining how clients are being generated.  It will also make converting clients back to prospects after keying errors simpler. 

Partitioning a table like a customer table is likely to be of little use.  Hot clients will likely be cached at the database or o/s block buffer level.  If you have the ID it is pretty well a direct look-up.  

Transactional data is more suitable for partitioning.  Order details can age out in hours depending on order processing times.   Customer data will likely take years to age out.   I don't see any data in the table which could be used to effectively partition the data base on 'hotness'.   I have generated an archiving system for customers and their data.  Determining the customers which could be archived was not trivial.