Brute force attacks are also possible with full page reloads. If you are afraid of abuse, try implementing tar-pitting. Or do not block based on usernames, but only on username-IP-address combinations.

What lammert said. Also, you could temporarily store the user input into the session data so that you it won't be lost on a "reload". However, a quick AJAX check could certainly make the process more user-friendly.

Strictly speaking, Google Ads shouldn't be placed on pages that offer no content, like registration, sign-in and error pages.

Hmm, I like the idea of temporary blocks based on username-IP or maybe username-useragent combos. I'm not sure if there's a way to auto-delete entries from MySQL after a certain period of time without a cron, but I'll probably address that one later.

Strictly speaking, Google Ads shouldn't be placed on pages that offer no content, like registration, sign-in and error pages.

True, and I don't have it on pages that ONLY log in. But in this case the post form is at the top of the page with the rest of the content, sorta like how the reply section on this page is below the content. I think that very few people would type up a comment and then click an ad before submitting it, so I'm guessing that bringing them back to the same page to try submitting again would just result in more ad views but a lower ratio of clicks.

There are few things here:

First UI/UX, I would allow the user to fill in the message form fully, subject and message body and only prompt for login on "send". User that are not already logged in should then be prompted to login. Like this the user has already committed time and energy into filling the form, he/she is more likely to login.

From a security perspective there is no difference between ajax and not ajax, a brute force attacker will not go to your page with the form and "click" submit each time, that is way to slow. The attacker will "create" the form programatically without the browser and send it directly to the form's endpoint. So whether the page refreshes or not after form submission is not a factor.

Moreover, you should only have one login method, you can re-use it in different places on your website but it should only be one. There will be only one login point to defend. If there is only one login point then whether the user chooses to login from the home page or from a message submit form will not change anything in terms of security.

you wrote:

I could temporary block an account after X failed login attempts

As you have concluded on your own this probably isn't the best approach.

@lammert answered

If you are afraid of abuse, try implementing tar-pitting.

I haven't header the term tar-pitting, I assume that means progressively slowing the login process. There are many ways to do this, one approach is to simply slow the login process, which makes it annoying for every user. The most common approach I see, is, after one or two failed attempts to show a captcha.

Another way to defend against brute-force attacks, which isn't mutually exclusive with the above, is the ensure that users passwords are long enough and strong enough. You can use a library like zxcvbn. There are versions available for most common languages. Here is a link:
[github.com...]

I don't know whether or not your are familiar with CSRF attacks:
Attack from "not logged in" users is not the only concern, another type of attack to guard against is CSRF attack (Cross Site Request Forgery). This is where an attacker sends, to a logged in user, a link, typically in the form of an image with an src that is "invalid" in terms of an image but instead points to your endpoint but with a valid uri, thus hijacking the "logged in" users credentials, and in your case sending messages on behalf of that user, without the user's knowledge.

I've been working on implementing a new sessions/account authentication system for my site, so I have been reading a lot about this over the last few days. I've concluded that @lammert's advice is probably not optimal:

Or do not block based on usernames, but only on username-IP-address combinations.

As this will not prevent an attackers with a sufficiently large number of ip addresses from launching a successful brute-force attack. One must block all login attempts to the username alone. Moreover, the most likely user to make repeated attempts with the same username password combination is the legitimate owner of the the account that has forgotten the password. So there is still high probability that you will lock out the legitimate user.

The concern is that by blocking accounts by username only, it makes it easy for an attacker to maliciously block legitimate users from accessing their accounts. To prevent this, the solution I've come up with is to open a side channel. When the account is locked out, one sends an email (could be SMS) to the user informing them that the account is locked and provide them with a temporary link to a login page that allows them login while bypassing the account lock. One could also at the same time provide them with the means of resetting a forgotten password.