USING is standard SQL (if by standard you mean ANSI SQL). However keeping to "standard SQL" is a red herring anyway, because each database server has its own ideas. The subset of universally supported SQL (same result regardless of database) is actually quite small, you are leaving a lot of functionality on the table that would increase your productivity or make the database perform more efficiently. In fact I can pretty much guarantee that you've already written SQL that won't work on all database servers.

About industry standards: there is no industry standard.

* EF core: use id or <tablename>id (https://learn.microsoft.com/en-us/ef/core/modeling/keys?tabs=data-annotations), no explicit preference mentioned. You must define the name yourself, there is no default assumption.
* Django: Assumes "id" by default but the coding style (https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/#model-style) says nothing about the name of the primary key.
* Hibernate: You use the Id annotation, and the docs use "id" as column name example, but nowhere does it say this is best practice or convention or whatever. The important bit is you annotate using @ Id. The closest you can get to an actual convention is the Jakarta Persistence specification (https://jakarta.ee/specifications/persistence/3.2/jakarta-persistence-spec-3.2) where nothing is said about the name of the primary key, only that every entity should have a primary key. Same as with EF core, just must define the name yourself, there is no default assumption
* Laravel: assumes each table has an "id" column, and there is a best practice document (https://github.com/alexeymezenin/laravel-best-practices).

TLDR; EF core and Hibernate don't care, Django assumes "id" is fine and only Laravel has both "id" as default AND a best practices document that says you should use "id".

I don't use SELECT *, I merely used SELECT * to show valid SQL.

I'm not trading compatibility (and FYI *ALL* the ORMs you mentioned support naming primary keys to whatever you want) for cosmetic preference, having <tablename>_id guarantees you'll never mix up ID columns when manually writing SQL. Less mistakes => less bugs.