Here's a short write up on stuff that one should take away from those "15 commandments."
1. Thou shalt read the manual and seek guidance within before asking others.
Read the GMS manual for the specific thing you're battling with. Look around on the web to see if your question has been asked, and if a solution was found.
2. Thou shalt not use Drag and Drop.
This is completely dependent on the user. Telling someone who hasn't got the slightest clue about GML that they should never use D&D, is about as useful as it sounds. When you're starting out in GM, using D&D is absolutely fine. A lot of the best games you've played (that were made in GM, at least) had some D&D in them, somewhere or another. D&D is essentially just shorthand for code. It's not the best way to achieve what you're trying to do, but if it's the only way you know, work with it for now.
3. Thou shalt manage thy white space.
Tab your code out nicely. It doesn't have to follow any kind of exactly style, as long as it's consistent and readable for future you. If it's code that you're giving to other people, try to make it understandable for them, too.
In fact, it does have to follow an exact style. Every time you put a curly bracket {} on the same line as the statement that precedes it (I.E "if (a==b) {") and angel loses their wings and a portion of your RAM is sold into crypto-mining slavery.
4. Thou shalt name thy variables descriptively and consistently.
Self explanatory, really. Name your variables after sh*t you'll understand later on. Duh.
5. Thou shalt not use persistent rooms.
This absolutely depends on what you're doing. Making a mini game where someone has to walk between two rooms and pick up a couple of items - go wild. This really only pertains to SAVING later on, but it's only an issue if you don't understand what GM is doing 'under the hood.' Avoid using it, but if it were something that was never meant to be used, and had thousands of issues... it wouldn't be in the engine.
6. Thou shalt not use the physics engine if your game does not require a physics simulation.
A lot of people may agree with this. There are much better ways to handle collisions without the use of Box2D... but if you want to, and you understand what you're doing, then go nuts. This is really more about personal preference and understanding of how Box2D works with GM.
7. Thou shalt not make thy pixel art game any larger than 960 x 540
This is because it isn't necessary in most cases.When it comes to pixel art, the goal is for the game to look and feel retro, most of the time. GM is not going to crash and burn if you use a greater resolution than this. Most of the stuff I make in GM is 1920 x 1080, running at 60FPS. And hell, this is also entirely dependent on what type of game you're making. I've made pixel-art games that run at 1080p, 60FPS with absolutely no issues whatsoever. This is just a really weird thing to pick on.
8. Thou shalt not use Object Following for your game's camera.
This is also perfectly acceptable. There are ways to do it through code, but if you're just doing something fairly simple, that isn't going to require anything more than what Object Following has to offer... why would it be an issue? If it works, it works.
9. Thou shalt use double equals (==) when comparing values.
Yes.
10. Thou shalt not use 1 in place of True nor 0 in place of False.
This one is just ridiculous. If you cannot look at a 0 where a true or false would be expected and instantly go "Oh, that clearly means false!" Then you shouldn't have taken up this gig. 0 - false. 1 - true. It's not rocket science. There is absolutely no difference at the machine level. This is purely an aesthetic thing.
11. Thou shalt not use magic numbers.
This is good advice, overall... but once again, it depends on the situation. If I'm making a tool, or a bit of software in GM, and I know that 100% of the time, I'm going to need to draw something at a very specific position... why would I want to assign variables to that? In that case, you're just wasting memory.
12. Thou shalt not use the "self" keyword.
Sure. It's basically just here for legacy support. It's never REALLY necessary anyways.
13. Thou shalt not preemptively worry about performance issues.
Absolutely awful advice. Why would anyone EVER tell people not to worry about optimizing their games as they're coding them. Sure, don't fret over the super minor stuff... but optimize your code where possible, while you're writing it. It'll save you literal hours of work down the road, trying to find where the bottle neck in your game is coming from. Awful, awful advice. If this 'commandment' was a human being, I'd throw it down a well and build a high rise on top of it.
14. Thou shalt not use the "Solid" checkbox, nor the associated scripts.
If you're writing an entire, massive game - this is probably some great advice. However, once again, if you're just working on a small project, or you understand how GM handles this setting and its related scripts... go ahead. If you know what you're doing, and understand how to change things later on, if you REALLY want to, then use this method.
15. Thou shalt use the Draw GUI event to draw things relative to your game window.
This is also completely dependent on your specific needs. There are many situations where using Draw GUI is helpful, and there are many where you may want to approach the problem from another angle. I.E. Draw GUI does not take depth into account. It draws on top of everything, in order of each object's time of creation. If you understand how Draw GUI works, use it. If you don't, learn about it, or stick to the way you know how. Because it makes very little difference to the overall outcome of your game, or the performance as a whole.