Are there attempts to standardize G-code for FFF/FDM printers? Rep-Rap project wiki contains information about different G-Code dialects for FFF/FDM 3D printers.

I googled but couldn't find if there were any attempts in DIY community to standardize existing dialects more or less?

For example, M115 command should return meta-information about firmware version and capabilities. But almost each popular firmware doing it in a slightly different way: sometimes they are just using different separators, sometimes constants are structurally different as well.

The result (as I see it) is some standard subset of G-Code commands that can be extended with dialects from different firmware providers. Probably something similar (but better) to what's is SQL world.

Are there any major cons for doing this?
G-Code Is RS-274/NGC
There is no need to attempt to standardize G-Code, the G-code itself already is standardized: it is the NIST RS274/NGC, or often short AIN RS-274 and was not designed for just FDM printers but any moving tool. Power lathes, CNC and laser cutters all can run on RS-274! G0 and G1 always move, G28 is always the homing procedure and so on. To show how the RS-274 standard evolved over time, check out an older variant of the document, the NISTIR 597 Canonical Machining Commands.
Implementation is not standardized!
However, due to the design of a given machine, the exact procedure for these commands has to be different for different designs. For example in a carthesian, prusa style printer Homing is usually moving negatively in X, Y and Z, in that order, one after another. But in a Delta Printer, that would most likely get your printhead to an illegal position: the printhead would first be moved out of the print volume and then never hit any endstop as those are mounted at the top of the printer. Instead, all axis on a delta are moving up simultaneous on homing, stopping each axis as they hit their endstop at the top, then the whole setup moves down to the printbed in unison. On a mill, lathe or router, the G28 operation usually starts by backing the tool away from the work volume, then moving to the 0 and only then moving the tool back into the work area to avoid fixtures.
G &amp; M-command gaps
Another caveat is, that the standardization via the NIST document only encompasses codes G0 to G99 and M0 to M49 - with gaps. Which brings us to the code block M - Miscellaneous. It is not fully defined in the document. FANUC setup uses a few more common M-commands but might contain more. The CNCcookbook has only 16 common M-commands, none of them a reporting one. Autodesk declares even only 11 M-block commands most common: M0 to M9 and M30. Of these the coolant related ones are usually irrelevant for FDM.
M115
M115 and M503 are reporting functions outside of the areas that were pretty much defined by the norming agency and thus have cropped up as development needed them until they formed undefined de-facto industry standards. This means that the standard itself does not contain them, but everybody and bob know that these commands are meant to report firmware and report settings respectively because some popular machines started with it.
These two commands are to inform a programmer what is the brains of the machine and settings, and as such, they are also subject to the style guide of the programming institution - the norm document does not contain a style guide, leaving it free for any implementation to chose style. A working example is Marlin's M115.
However, there are reasons why a programmer might disable M115 but keep M503: Industrial machines, especially such with maintenance contracts, usually don't allow users to access the firmware in some ways to on one hand keep them out from messing with the machine too much and on the other make sure that only a licensed technician can access some reporting functions by using proprietary commands. M503 on the other hand reports on the current status of settings that might be changed by the user or their service technician to account for different print requirements.