I've experienced the following:
First, there are certain structuring choices Grass makes that are different than QGIS does. You may conceptually prefer these choices, and pragmatically if you plan to use Grass functionality extensively in your workflow for a given task, your life will be easier if you use Grass tools and modules and therefore make the necessary translations only once, and you will save time since the Grass-QGIS interface is not doing rework everytime you invoke a Grass algorithm to set it up ad-hoc.
I'm sure others will add more, but the two biggest choices of this type I've experienced are:
Raster analysis is/can be done in regions. See https://docs.qgis.org/testing/en/docs/user_manual/grass_integration/grass_integration.html#id25.
Grass works with topological areas (boundaries + centroids) rather than (nontopological) polygons. See https://docs.qgis.org/testing/en/docs/user_manual/grass_integration/grass_integration.html#the-grass-vector-data-model. If your data is naturally topological (e.g. you are tiling your ROI, no intersections), you will save processing time and headache by working natively in a Grass mapset versus having your vector layers go through
v.in.ogr (and implicitly I believe
v.clean) every time you invoke a Grass processing algorithm.
Second, there are a few bugbears about QGIS-Grass interaction which seem to pop up far too often even if they are small, and require workarounds you will find annoying if you are repeatedly invoking Grass processing algorithms within QGIS.
Custom CRS specifications. Maybe this has now been fixed, but with the passage to proj6 in QGIS 3.10.x in particular, working in a custom (non-EPSG) CRS with Grass processing algorithms was painful, with result layers having to have their CRS reset in QGIS in particular. I believe a Grass Mapset sets one CRS, so whatever you're doing with CRS, you only do it once if you go that route!
Raster nodata values and mask parameters can take tweaking to pass to to raster algorithms invoked by QGIS, e.g.
r.neighbors. If you do this often, it's easier to work within Grass and be clear what nodata is once and for all.
Finally, there is an important (potential) disadvantage - to use Grass tools you have to set up a mapset and adapt to Grass' mapset/location file model, and single CRS (versus reproject on the fly). You're clearly aware of this, but for the benefit of others reading this, see https://docs.qgis.org/testing/en/docs/user_manual/grass_integration/grass_integration.html#grass-location-and-mapset