There is nothing wrong with tens of columns in a table. Depending on the property types it can be more efficient in terms of space than a separate properties table, and it is almost always faster to query if you want several of the properties at once in one row of a resultset, i.e. it you want to return:
Thing Prop1 Prop2 Prop3
----- ----- ----- -----
T1 T1P1 T1P2 T1P3
T2 T2P1 T2P2 T2P3
Thing Property Value
----- -------- -----
T1 P1 T1P1
T1 P2 T1P2
because you won't have to have many joins (or, worse, subqueries) to the properties table to transpose the data. Of course if you regularly need the data in this transposed format then this recommendation is reversed as you'll need to transpose the other way (with several unions) otherwise. Even if your DB has efficient transposition functions, make sure the data is in the arrangement you are most likely to need it in most of the time.
Most DBs allow many columns per row and are often not much less efficient with wide tables than they are with thin ones (unless you "select *" all the time and/or have bad index choices).
The massive caveat to the above is that you should be careful that you are not creating a nightmare for yourself by way of denormalisation. We could only give advice on that matter if we knew what the column contents were expected to be.