Separating data to different tables relating to the same object
One concern with a large column counts is to do with the number of rows which can fit in a page. DBMS performs IO one fixed-size page at a time. If any part of a page is needed, all of it is read into memory where the required bit is processed. So, if there are a small number of short columns many rows can fit in a single page. Conversely tables with many, long columns can only fit a few rows per page and more IO is required to retrieve a given number of rows.

Is this good or bad? Well, it depends. (If you're new to database design you'd better get used to hearing that phrase!) If you only ever look for a single row at a time it would be better to have all the columns in single table so one IO will return all the values to memory. They are likely to stay there for a while, meaning subsequent actions on the row will not have to do physical IO. This is great for a typical transaction processing workload where an item goes through a number of steps until it reaches completion.

If your workflow is more BI oriented, where you need sums and averages and whatnot, then a query will retrieve many rows and will benefit from having as many rows per page as possible. Ideally, those rows should only have the columns required to answer the query. Other columns would be better held in a secondary table.

Sadly, few systems are this cut-and-dried. Often there is a mix of OLTP and BI work. No one query is so much more important than the others that it drives the DB design. The additional IO cost of referencing a secondary table can be troublesome. This is where the art takes over from the science of being a DBA. You have to understand the intended usage and juggle options accordingly.

For my two cents, without any understanding of your actual workload whatsoever, I'd suggest you keep everything in a single table for now. Anything else is premature optimisation.  When you run into an actual problem you can't solve another way, that's the time to split tables. The additional complication of keeping the secondary tables synchronised with the primary can be surprisingly tricky.

Before then covering indexes will help a lot. Materialised views are useful, too. Neither are free lunches, of course, so understand the costs and benefits before deploying either.

Should you decide to split over several tables I'd suggest keeping together those columns which are used together in a single business action. Mixing read-only and updatable columns in a table is not a problem. I can think of no advantage of separating them on those lines only.