It sounds like you're talking about typing, not syntax, C++ and Java are strongly typed languages, their syntax is not actually much more "strict" than other high level languages, I have about equal syntax freedom in PHP 7, Java, and C++, but JavaScript has a little bit more "freedom", in the sense it allows you to do asinine things like not have semicolons at the ends of lines. This is something crappy Ruby and Python programmers sometimes love doing since they rail against semicolons, of course making their JavaScript harder to debug and impossible to compress.
Anyway...
Weak typing is easier for beginners, but it can make things difficult for larger, more complex projects; this is something we kept bumping up against in PHP, which is why PHP 7's strict typing is great and we've saved a lot of debugging headaches and dealing with other problems by making everything strictly typed.
Both PHP and JavaScript allow both static and dynamic comparison regardless of type strictness, for example:
1 == "1" True
1 === "1" False
The strict comparison is good for several reasons, however even in JavaScript there's a few issues with it, because JavaScript types in-of-themselves are not very good. There's not only a single object type which creates insane and unexpected results but there's also only a single numerical type as float, so:
0 == 0.00000000001 True
Languages like C++ and Java always have type strict comparison, so it's as if you're typing === every single time.
Having said that, when it comes to strict mode, those are different depending on the language. In PHP it's related to typing and how objects are handled (non-static properties cannot be accessed statically, for example), however in JavaScript it's primarily related to variables and object properties, all of the type issues still exist regardless.
Should you use it? In JavaScript absolutely always, because it helps make up for some of the language's flaws which can get you into trouble debugging later on. When it comes to PHP always have E_ALL | E_WARNING | E_NOTICE | E_STRICT | E_PARSE set in your php.ini (or barring that, set in .htaccess) and if you're using PHP 7 take advantage of the strict typeness, but even if you don't want to use PHP 7's new strict typing, properly log errors.
Do it right the first time.
As @JaredBusch said above, when I don't see it enabled, it's just a sign of the horrors to come. Even well written JS code will have errors typically in it when people don't use strict.
In the amateur programming world, especially PHP (but also JavaScript) there's a desire to simply hide warnings, notices, errors, etc rather than fixing them. This is like taping over your check engine light on your car and assuming it's now completely fine.
In other words, if you feel as though you should be able to suppress syntax and type errors knowingly, you should not program; get someone else to do it. I sometimes hurt feelings saying this, but if you approach any other job in a similarly lazy manner, you'd be fired or in some cases imprisoned when your building collapsed or killed someone.
In actuality, programming errors have killed people, maybe yours won't, but that's no excuse to intentionally do a bad job because you're lazy. It's bad for your customers, bad for your environment, bad for your users, and bad for you when things fail and break and you don't know what went wrong because instead of logging properly and completely, you suppressed everything.
In addition to returning to projects much later, laziness with typing and also syntax causes people to write bad code initially so later on they have a much harder time reading their own code or debugging. Some people say this doesn't happen to them, perhaps with tiny scripts that's true, but beyond that they're just lying, or they're stupid.
So no, it's not awesome, and I've personally had to fix cases where ignored notices from PHP created failed database queries and data loss, as well as incomplete data states, and there's the recent example of a similar declaration problem leading to a guy deleting all of his customer data, that is also an example of why you don't program in production, another massive problem out there.
Either turn on all warnings and notices, enable strict everywhere you can or stop programming, no matter what it is you're working on. There's enough bad code out there, fix your approach before you get too old to do it and you're that old programmer everyone hates or that old IT guy who writes bad scripts which break things everyone else has to fix.
So when starting a project or script, if you want to hide PHP's warnings or notices or keep JavaScript from being strict remember to tell yourself, clients, and anyone else that "I'm starting this new project and I'm going to do a terrible job at it," because you will, it's inevitable.
So I agree with @scottalanmiller, it depends on what your goals are, either to write something that works and is easier to maintain later on, or to write garbage to create a hell for yourself and other people which may or may not destroy data and lose things with no further information as to what went wrong.
Now that you know the importance of it, any decision otherwise beyond this point is being intentionally stupid and reckless.
