It was a long, winding road to reach the root cause. Jump to "Final Update" below if you're only interested in the destination, not the journey.
Per :h FileType the FileType event doesn't do anything unless 'filetype' is set. The standard way to set that is to have this in your vimrc/init.vim:
:filetype on
This "enables file type detection".
You don't have anything in your init.vim so that's surely why this stuff isn't working "out of the box". Your Session.vim file, which contains a bunch of config, likely was created when filtype was enabled. That's why things work after you source it.
BTW, you should be doing autocommands like this:
augroup myautocmds autocmd! au FileType * echom "test" augroup END
This allows you to safely re-source the file containing your autocommand(s).
Update: Okay, current state of affairs is that everything is working with above, generally speaking, but echom doesn't not produce any visible output. I use echom in autocommands in Vim but I'm wondering if filetype event specifically poses a problem. Other actions, e.g. setting a variable, work fine. Investigating further...
Update 2: After it's all said and done it looks like it boils down to this: echom with FileType autocommands is not reliable. Works with other event types. Works with Vim. Not with Neovim and file type. If OP happened to use a different command (e.g. set a variable and checked the value) they might not have ended up here at all.
(Opening a bug with Neovim might be prudent.)
Update 3: Just to formalize the conclusions I automated some tests so I could be sure that there is a discrepancy between Neovim's behavior and Vim's...as opposed to some human error leaking in. Tests were parameterized over several permutations of auto-command event types, auto-command patterns and minor variations of the actual commands run. Specifically, I tried both direct and indirect calls to echom. (Indirect: echom put in a function and the autocommand calls the function.) For the indirect cases I also wrapped the echom calls in redir so, in theory anyways, the messages would appear in both mess command output and in a temporary file.
Results didn't turn up any surprises...
Vim (and gvim) consistently showed echom messages in real-time and when viewed with mess for all tested event types as long as the pattern used was valid. For the indirect command calls all messages also showed up in the redir files.
Neovim had less consistent results. For event type BufEnter everything worked exactly as it did for Vim. For the FileType, BufRead and BufReadPre events the messages never showed up real-time or in mess output. The only cases that the echom call could be verified to have occurred at all with these events is with the indirect/redir test variations. In those cases the echom output always appeared in the redir file.
Anyways, I believe this concludes matters as far as StackExchange activities go. Next step, if someone wants to move things forward, would be to see what the Neovim maintainers have to say about it.
Final Update: Apparently this is due to a different default than Vim for 'shortmess' and removing F from its value will match Vim's behavior. Doesn't make me feel too much better about things as the behavior (affecting this autocmd but not that autocmd) is apt to cause confusion. (There have been a number of bug reports filed over this thing.)