It sounded like an import, so I wondered what source was used and whether it would also contain data for Thailand. Rendering of all those unnamed peaks is a bit weird, but this is a different story.

Can you document on how to get the AMS maps on the main page of Laos together with other data sources? osm.wiki/WikiProject_Laos

Where can these maps be obtained from? is this complete? Are there instructions somewhere on how to adjust projection and alignment and how to use as an imagery layer? I probably also ask directly Adrian for How-To details.
http://legacy.lib.utexas.edu/maps/ams/thailand/

For the large number of peaks, probably only document where they are from and what the source was in case others wonder about it as well.

I notice that your added POI line up very well with the few POI listed on google maps. Might be coincidence. But please be aware, that it is NOT allowed to copy details from google maps to OSM. We want to have the features verified on the ground. This is what makes OSM better than google. The features are actually verified (location and existence) and not automatically placed by some algorithm.

node/5346112264
For Wat Ban Chot I added religion=buddhist, as this helps to later render the right symbol on the map.

node/5346112262
a health center is also no place of worship. Please take extra care to select the right tagging, as this is the way in OSM data is described.

way/553888009
Residential roads (the roads in areas where people typically live) are tagged as highway=residential

node/5346112258:
This was placed at the exact same location than the mistagged school above. Please check the location, as imagery does not show any building there or nearby looking like a health center

for node/5346112257:
a mini mart is most likely a shop=convenience, not supermarket

For node/5346112259:
I don't want to discourage teachers around, but โรงเรียนบ้านโนนเพชร is *not* a place of worthip. amenity=school is much more appropriate for schools.

Welcome to OSM. Your newly created roads do not follow the reality. They are away from the real geometry of up to 200m. Please also make use of the other imagery providers available. In this case Digital Globe imagery is available and allows you to draw roads without guessing. Be aware that sometimes the imagery provided is not exactly aligned. So best is to check imagery alignment against GPS tracks first. As a rule of caution: If you are not certain regarding correct placement do not re-align existing things. In this change the situation is clear. I have aligned your geometry. Plese check the exact location of the POI you have added against the Digital Globe imagery and correct them as well. Especially these located away from the main road.

These are the unconnected ones. Are you in the process of adding a separate highway lane for 24 or shall I connect the to the existing road? I didn't want to interfere with ongoing mapping...

node/5345965541
node/5345963620
node/5345965527
node/5345965565
node/5345965705
node/5345965544

You created a lot of unconnected roads to highway 24, eg node/5345963620.
I hope it is due to you being in the process of making it separated by direction. Please check all the road connections to have a routable network. Thanks

You might be really knowledgeable, but hundreds of them including exact elevation? Your source statement sounds a bit strange. Can you please document this import including the source of the data?

I guess you did with best intentions, but your mapping needs a massive rework. Micro-Mapping mostly not justified by landuse pattern. Geometries uneven and partially overlapping/duplicating other features.
Guess your teacher is to blame. Can you please give details who directed you here and failed to do a proper review?

Let me guess: You had been mapping for a class, right? Please give details who directed you.

I guess you (and others) did with the best intentions, but unfortunately your edits lack in many ways.

That tagging is broken. Had you been there at all? "unknown" or "house" are not names.

"not sure" is certainly not the name of way/501292972.

Are you going to revert your things?

A Volcano? No further details and wrong tagging?

I am very tempted to count this as vandalism. Please give some details regarding this.

This is not a playground. It is a live database used by people...

I recommend to move the discussion to the forum thread mentioned above. That way we can document the decision better.

Might be an interesting decision whether to go for addr:*. is_in:* or completely remove those where admin boundaries are available.

I am not too keen on investing time to do a proper revert of something which also took you time to do.

I am personally undecided whether is_in is better or worse than addr tags in this situation. I always considered them only being a mid-term solution on the way to admin boundaries.

The thing to worry about is that some details are lost due to the tag change.

So please let's bring all those details to the forum.

Thanks for responding to the comment.

Doing a mass change of tags is considered a mechanical edit. Whether you are using JOSM or other tools is not relevant in this context.

It seems this change was not discussed with the community. Or was it somewhere?

I see the problem that some details had not been migrated when you changed the tagging.

For example here:
node/1684727085/history

you have removed other details, eg:
addr:district หนองสองห้อง

So you could argue that this can be derived from the admin polygones. But same is true for the is_in structure you had added.

Would be great if you could respond in the forum: https://forum.openstreetmap.org/viewtopic.php?id=60482
Opinions are mixed, so certainly something which should be discussed. There is also the option to first revert and then to re-apply the change and this time preventing the loss of details. Or maybe only reverting it partially based on criteria we can define.

this is clearly a mechanical edit. I do not see any documented prior discussion. Please give some details, as I am not convinced that replacing addr:* with is_in:* is the current standard.