Previously Brew data was stored in the data.yml
Brews get a unique id through their regeneration custom effect. This unique id points to the data entry.

Downsides of the old method:

• simply duplicating brews with any means other than /brew copy will not generate a new unique id for the brew. This means drinking or destroying one of the copies will remove the data entry and render all other copies useless. There was added a persist command but that is annoying.
• Brews removed though unhandled methods, be it deleting of player files, removing with any world editor etc will keep the data entry orphaned.
• All data entries for a loaded world are loaded at any time, even if the potion is actually hidden in some chest
• copying a brew to another server (through schematics etc) will have the data entry missing or even conflicting
• data scattered all over the place

Advantages of the old method:

• less data overall, every batch of brews only needs to store the reference to the same ingredients, now every item has to store everything
• Data is never sent to the client
• All data accessible at all times, to do some updating operations

Ways to accomplish storing on item:
NBT:
Not accessibly though bukkit api. Would have to use reflection to access the nbt methods. Could break in the future. Data could confuse some implementations, other plugins or the client if it is sent. Some implementations may skip custom nbt when serializing.

Lore:
Needs to be stored as String and be twice the size because every second character needs to be an § to make the String invisible in the lore. Should work as long as lore is accessible. All implementations should support lore anyways. Is sent to the client, but invisible lore does not render at all.
Development started here https://github.com/DieReicheErethons/Brewery/tree/2.0-StoreDataInLore

Bukkit has an official API for custom tags as of 1.13.2.

TBH I think NBT tags are way cleaner than hidden lore. It would be nice to have some kind of unique identifier (like a name that cannot be changed using an anvil) in a lore line for custom textures with OptiFine's CIT function, but detailed data just makes more sense to me in NBT tags. I've made good experiences with NBT so far for example in DungeonsXL.

As is said above, NBT is not accessible through official api and may break, change, be deleted or unreadable in the future. Also it is not guaranteed to be deserialized though Bukkit methods (in the Barrel for example), or to work in itemStack.equals(). Other Plugins have no way of knowing it is there and it might be stripped of the item by accident.
I think even though in the Lore might not be as clean, it is the most compatible way to do it and its just a single place to worry about.

This has been implemented in v2.0 with nbt for 1.13 and up and invisible lore for 1.12 and lower

Yes, please. Such a bother.