This isn't so much an SEO issue, as an issue as to whether your site would work at all. If it doesn't work in the browser then it's certainly going to hurt your SEO.
Your HTML pages still need to return the text/html mime-type in order to be interpreted as HTML by the browser. ie. You need to send a Content-Type: text/html HTTP response header somehow.
Ordinarily, Apache uses the file extension to determine the mime-type (using the AddType directive), from which it generates the Content-Type HTTP response header. If there is no file extension then it's going to return whatever default your server is set to return for unknown file types. (Bear in mind that this "default" could be nothing at all, ie. no Content-Type.)
In other words, with the text/x-generic type.
If the server sends a text/x-generic Content-Type then the browser is likely going to see the response as plain text and display it just as plain text. ie. the users see the raw HTML source.
Also, whilst your server might be configured to send a text/x-generic response as a default - that is by no means standard. Many servers will default to application/octet-stream, which will likely trigger the browser to download the file. ie. The user might see a "Save As..." dialog.
The intended default on Apache 2.4 is no Content-Type at all. So, it is left for the browser to interpret the response and decide for itself. However, this could naturally result in different responses from different browsers as I don't believe there is any "standard" here.
We don't need the .htaccess rule in such case
But you need something to "fix" the Content-Type header.
Workaround (well, kind of ...)
In comments, the possibility of setting the default mime-type in .htaccess is mentioned. However, this is only available on Apache 2.2 via the DefaultType directive. For example, the following will return a Content-Type: text/html header for resources where the mime-type cannot be otherwise deduced.
DefaultType text/html
However, DefaultType does not work on Apache 2.4. It is only available for backwards compatibility (ie. it doesn't break the server - but it doesn't actually do anything).
On Apache 2.4 it is recommended to use AddType - in other words, the recommendation is to base the mime-type on the underlying file extension, eg. .html. So, by removing the file extension you are kind of going against Apache's recommendation.
Alternatively, you can use ForceType - but this forces the mime-type on all resources (depending on where you put the directive) - so this must be set conditionally. But what do you base this condition on? You could perhaps check that the filename does not contain a dot (or only contains a limited set of permitted characters), ie. it does not look like it has a file extension:
<FilesMatch "^[^.]+$">
ForceType text/html
</FilesMatch>
However, there could potentially be other issues:
How is your server setting cache headers? This could be based on the file extension, although it is preferable to set this based on the mime-type.
If you want to open these files in an editor... how does your editor treat extensionless files?
Summary:
You could do this, but I wouldn't. Rewrite the URL instead.
Reference:
DefaultType on Apache 2.2 and Apache 2.4ForceType on Apache 2.4- Mailing list archive that discusses
DefaultType (reasons for dropping in Apache 2.4) and ForceType and other possible (non-working) methods of setting the Content-Type header using the Header directive (although this is non-trivial due to the nature of the Content-Type header). (Aside: Note that it has only been possible to set the Content-Type header at all - with the Header directive - since Apache 2.2.12):
https://lists.gt.net/apache/users/443558
- Answer on SO that shows an apparent method for setting the
Content-Type header using the Header directive and expressions to conditionally set the Content-Type header only when it is not already set (references the above):
https://stackoverflow.com/a/37529835/369434
