If I am not wrong, this is the best practice because of the following reasons:

1. It fetches only the required columns, reducing the amount of data transferred. By doing this, it also limits the possible exposure of sensitive data.
2. SQL keywords should be consistently capitalized to improve readability.

Maybe for this particular case, using '*' after the keyword 'SELECT' could lead to the same result, but I think it is good to develop the habit of just fetching the required columns by using their names and thus avoiding the possible fetching of unnecessary or sensible data.

Not the Best Practices definatly

Read this: https://www.prisma.io/dataguide/postgresql/short-guides/quoting-rules#:~:text=In%20PostgreSQL%2C%20double%20quotes%20(like,specifically%20marked%20beginning%20and%20end.

In SQLite 3.2.8 you could use one or the other.

Why it doesn't accept double quotes?

In theory, yes. Bust in many cases the time saved by using a wildcard is more important. Plus, you can limit your sample to, let's say, 100 rows and not worry about how many columns you have there anymore.

didn't know that you can check in a parenthesis and use a function right after, i always used an "if" or "?"

there is a name for that use of parenthesis?, didn't find any on internet.

I left off the comma zero and preloaded the zero into the otherwise array, while ES6 had unpacking/destructuring arrays in mind and prior versions of javascript not so much--so I had unpacking/destructuring as a mental model at the time I wrote my solution. Surprised it isn't more common yet.

How would you approach this with ES6?

Is it bad practice to throw errors without handling them or just bad practice to throw them period? I happened upon your comment and I ended up searching the internet for clarification :)

I've edited the tests. Now you must use an insert statement for the tests to pass.

Thanks a lot for this helpful comment. I've updated the commented phrase in the cata.

Just added this. Thanks a lot for your comment!

I'm not sure there's any value in making description as difficult to understand as you did. Simple "write an insert statement" would be better.

Dont forget to remove the comments in the initial solution editor. Hopefully you don't do what I did and pushed the comments, "//Your Code Here", to the next line instead of completely removing them thinking it was an SQL comment and then proceeded to submit the solution, it's not an SQL comment. :)
Since I pushed it to the next line, it seems like the interpretor processed my insert then silently or gracefully exited afterwords without processing the subsequent SELECT statement at the bottom. I was bamboozled for a bit, more than I'd like to admit.

// Your code here (not an SQL comment; the interpretor will error out--hopefully not silently)
vs
-- Your code here (SQL comment the SQL interpretor will skip)

My Example:

SELECT
'Dont forget to remove the forward slash comments below when you do the insert'
FROM participants;

//Your Code Here

SELECT * FROM participants;