That will retrieve EVERY column from EVERY row in that table. Even if that is what you want you should always name the columns.
I don't know if your application code
$rs.Open($cmd) ACTUALLY RUNS that query, and if so if that is necessary in order to then do an ADDNEW? - if it is not actually running the query then that's not a problem, but you should still explicitly name only the columns you need.
(I would debug that by displaying the time before/after that
$rs.Open($cmd) command and seeing if that line is what is taking the time (unless you know that that is a PREPARE command rather than an EXECUTE one)
If you use SELECT * someone, in the future, might add an IMAGE column with 10MB per row in it (maybe they already did?!!!) and that will crucify your query ... and ... at that time you will have to Find & Fix every single query that uses SELECT * ... and retest the APP ... and deploy all that. The reason I know is that I was called in to solve exactly that problem where the Call Centre said "Can we have a little Notes field where we can record the details of the call in case someone else picks up the call next time" and their nice developers added that one column to several tables in the DB and ... guess what ... the call centre folk wrote their life's history in there! and the developers had used
SELECT * in every query throughout the whole APP
The other likely problem is that the table is suffering (now it has got big) from a number of possible ailments:
If it does not have a CLUSTERED index then housekeeping may not be adequately removing / reusing space from deleted rows. Solution is to create a Clustered Index (or make the Primary Key on the table CLUSTERED). It would be much better to create a Unique clustered index if you can, and if you have a choice select a column(s) that is NOT NULL and has the narrowest column(s), for the key(s), that make the clustered unique.
Then Rebuild the all indexes on the table
Then Update all the statistics on the table (somewhat redundant as the Index Rebuild will have updated stats too, but there are likely to be other non-index Stats)
If that sorts it out then it probably means that you don't have any housekeeping running on your database, or it is not running often enough, or it is running often, but for a limited time, and is not prioritising the "most needy tables", in which case it would be worth putting that right, going forwards.